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Abstract — A  major  problem  in  verifying  the  security  of  code  is  that  the  code’s  large  size  makes  it  much  too  costly  to  verify  in  its 
entirety.  This  paper  describes  a  novel  and  practical  approach  to  verifying  the  security  of  code  which  substantially  reduces  the  cost  of 
verification.  In  this  approach,  a  compact  security  model  containing  only  information  needed  to  reason  about  the  security  properties  of 
interest  is  constructed  and  the  security  properties  are  represented  formally  in  terms  of  the  model.  To  reduce  the  cost  of  verification,  the 
code  to  be  verified  is  partitioned  into  three  categories  and  only  the  first  category,  which  is  less  than  10  percent  of  the  code  in  our 
application,  requires  formal  verification.  The  proof  of  the  other  two  categories  is  relatively  trivial.  Our  approach  was  developed  to 
support  a  Common  Criteria  evaluation  of  the  separation  kernel  of  an  embedded  software  system.  This  paper  describes  1)  our 
techniques  and  theory  for  verifying  the  kernel  code  and  2)  the  artifacts  produced,  that  is,  a  Top-Level  Specification  (TLS),  a  formal 
statement  of  the  security  property,  a  mechanized  proof  that  the  TLS  satisfies  the  property,  the  partitioning  of  the  code,  and  a 
demonstration  that  the  code  conforms  to  the  TLS.  This  paper  also  presents  the  formal  basis  for  the  argument  that  the  kernel  code 
conforms  to  the  TLS  and  consequently  satisfies  the  security  property. 

Index  Terms — Security,  verification,  specification,  security  kernels,  tools,  formal  methods,  software,  software  verification. 
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1  Introduction 

critical  objective  of  many  military  systems  is  to  protect 
the  confidentiality  and  integrity  of  sensitive  informa¬ 
tion.  Preventing  unauthorized  disclosure  and  modification 
of  sensitive  information  is  of  enormous  importance  in 
military  systems  since  violations  can  jeopardize  national 
security.  Compelling  evidence  that  military  systems  satisfy 
their  security  requirements  is  therefore  required.  A  promis¬ 
ing  approach  to  demonstrating  the  security  of  code  is 
formal  verification,  which  has  been  successfully  applied  to 
algorithms  such  as  floating-point  division  [1]  and  clock 
synchronization  [2]  and  security  protocols  such  as  crypto¬ 
graphic  protocols  [3],  [4].  However,  most  previous  efforts  to 
verify  security-critical  software  have  been  extremely  ex¬ 
pensive.  One  reason  is  that  these  efforts  often  built  security 
models  containing  too  much  detail  (see,  for  example,  [5])  or 
tried  to  prove  too  many  properties  (see,  for  example,  [6]). 
The  result  was  that  model  building  and  property  proving 
were  prohibitively  expensive. 

A  challenging  problem  therefore  is  how  to  make  the 
verification  of  security-critical  code  affordable.  This  paper 
describes  a  novel  and  practical  approach  to  verifying  the 
security  of  software  that  significantly  reduces  the  cost  of 
verification.  This  approach  was  formulated  to  support  a 
Common  Criteria  evaluation  of  the  security  of  a  software- 
based  embedded  device  called  ED  (Embedded  Device). 
Satisfying  the  Common  Criteria  required  a  formal  proof  of 
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correspondence  between  a  formal  specification  of  ED's 
security  functions  and  its  required  security  properties  and  a 
demonstration  that  ED's  implementation  satisfied  the 
formal  specification.  ED,  which  processes  data  stored  in 
different  partitions  of  its  memory,  must  enforce  a  critical 
security  property  called  data  separation  to  ensure,  for 
example,  that  data  in  one  memory  partition  neither 
influences  nor  is  influenced  by  data  in  another  partition. 
To  guarantee  that  data  separation  is  not  violated  (or,  if  it  is 
violated,  an  exception  occurs),  ED  relies  on  a  separation 
kernel  [7],  a  tamper-proof  nonbypassable  program  mediat¬ 
ing  every  access  to  memory. 

The  task  of  our  group  was  to  provide  evidence  to  the 
certifying  authority  that  the  ED  separation  kernel  enforces 
data  separation.  The  kernel  code,  which  contains  on  the  order 
of  3,000  lines  of  C  and  assembly  code,  was  annotated  with 
preconditions  and  postconditions  in  the  style  of  Hoare  and 
Floyd.  To  provide  evidence  that  ED  enforces  data  separation, 
we  produced  a  Top-Level  Specification  (TLS)  of  the  separa¬ 
tion-relevant  behavior  of  the  kernel,  a  formal  statement  of 
data  separation,  and  a  mechanized  formal  proof  that  the  TLS 
satisfies  data  separation.  Then,  the  annotated  code  was 
partitioned  into  three  categories,  each  requiring  a  different 
proof  strategy.  Finally,  the  formal  correspondence  between 
the  annotated  code  and  the  TLS  was  established.  Five 
artifacts — the  TLS,  the  formal  statement  of  data  separation, 
proofs  that  the  TLS  satisfies  data  separation,  the  organization 
of  the  annotated  code  into  the  three  categories,  and  the 
documents  showing  correspondence  of  the  code  to  the  TLS — 
were  presented,  along  with  the  annotated  code,  as  evidence 
supporting  the  certification  of  ED. 

This  paper  summarizes  the  process  that  we  followed  in 
producing  evidence  for  the  Common  Criteria  evaluation, 
describes  the  artifacts  developed  during  the  process,  and 
presents  the  formal  argument  justifying  our  approach  to 
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establishing  conformance  of  the  code  with  the  TLS.  The 
paper  makes  two  major  contributions.  First,  it  describes  a 
novel  technique  for  partitioning  the  code  into  three  different 
categories  and  for  reasoning  about  the  security  of  each 
category.  This  technique  dramatically  reduces  the  cost  of 
verification  (see  Section  3.4).  Second,  it  describes  an  original 
and  practical  method  for  demonstrating  the  security  of 
code.  Although  the  method  combines  a  number  of  well- 
known  techniques  for  specifying  and  reasoning  about 
security  (for  example,  a  state  machine  model,  an  access 
control  matrix  [8],  mechanized  reasoning  using  PVS  [9],  and  a 
demonstration  of  correspondence  between  the  TLS  and  the 
annotated  code),  which  techniques  should  be  applied,  how 
they  can  be  applied,  and  how  they  can  be  combined  were  far 
from  obvious  and  required  significant  discussion  during  the 
course  of  the  project.  Along  the  way,  many  alternative 
approaches  and  techniques  were  considered  and  several 
were  discarded.  What  is  notable  about  our  effort  is  that, 
unlike  many  other  efforts  applying  formal  methods,  ours  was 
not  a  case  study  but  a  successful  application  of  our  formal 
techniques  in  the  certification  of  a  real-world  system.  Both 
our  technique  for  partitioning  the  code  and  our  method  for 
proving  the  security  of  the  code  should  prove  cost-effective  in 
future  efforts  to  verify  the  security  of  software. 

This  article  is  organized  as  follows:  Section  2  reviews  the 
notion  of  a  separation  kernel,  summarizes  the  requirements 
of  a  Common  Criteria  evaluation,  and  presents  some  details 
of  ED.  Section  3  describes  the  process  that  we  followed  to 
demonstrate  data  separation  and  describes  the  five  artifacts 
that  the  process  produced,  including  the  three  categories  of 
code  and  the  demonstration  that  each  category  of  code  is 
secure.  Section  4  adapts  the  classical  theory  of  refinement 

[10]  to  the  proof  that  a  concrete  state  machine  model 
conforms  to  an  abstract  state  machine  model,  thus  provid¬ 
ing  a  formal  basis  for  proving  the  security  of  the  kernel. 
Section  5  discusses  the  general  class  of  security  properties  to 
which  our  techniques  apply,  that  is,  the  class  of  properties 
that  are  preserved  under  refinement.  It  has  been  shown  that 
safety  properties  belong  to  this  class  of  properties  [10]. 
Section  5  also  discusses  how  our  approach  could  be  used  to 
prove  additional  properties  of  the  kernel.  Sections  6  and  7 
describe  some  lessons  learned  and  four  topics  requiring 
more  research,  for  example,  the  need  for  more  powerful  tool 
support.  Section  8  discusses  related  work.  Finally,  Section  9 
presents  some  conclusions. 

2  Background 
2.1  Separation  Kernel 

A  separation  kernel  [7]  mimics  the  separation  of  a  system  into  a 
set  of  independent  virtual  machines  by  dividing  the  memory 
into  partitions  and  restricting  the  information  flow  between 
those  partitions.  Separation  kernels  are  being  developed  by 
commercial  companies  such  as  Wind  River  Systems,  Green 
Hills  Software,  and  LynuxWorks  for  military  applications 
requiring  Multiple  Independent  Levels  of  Security  (MILS) 

[11] .  In  a  MILS  environment,  a  separation  kernel  acts  as  a 
reference  monitor  [12]:  It  is  nonbypassable,  evaluatable, 
always  invoked,  and  tamper-proof. 


2.2  Common  Criteria 

A  number  of  international  organizations  established  the 
Common  Criteria  to  provide  a  single  basis  for  evaluating 
the  security  of  information  technology  products  [13]. 
Associated  with  the  Common  Criteria  are  seven  Evaluation 
Assurance  Levels.  EAL7,  the  highest  assurance  level, 
requires  a  formal  specification  of  a  product's  security 
functions  and  its  security  model  and  formal  proof  of 
correspondence  between  the  two. 

2.3  Embedded  Device 

The  device  of  interest,  ED,  processes  data  in  an  embedded 
system  whose  memory  has  been  divided  into  nonoverlap¬ 
ping  partitions.  Although,  at  any  given  time,  the  data  stored 
and  processed  by  ED  in  one  memory  partition  is  classified 
at  a  single  security  level,  ED  may  later  reconfigure  that 
partition  to  store  and  process  data  at  a  different  security 
level.  Because  it  stores  and  processes  data  classified  at 
different  security  levels,  security  violations  by  ED  could 
cause  significant  damage.  To  prevent  violations  of  data 
separation,  for  example,  the  "leaking"  of  data  from  one 
memory  partition  to  another,  the  ED  design  uses  a 
separation  kernel  to  mediate  access  to  memory.  By 
mediating  every  access,  the  kernel  ensures  that  every 
memory  access  is  authorized  and  that  every  transfer  of 
data  from  one  ED  memory  location  to  another  is  authorized. 
Any  attempted  memory  access  by  ED  that  is  unauthorized 
will  cause  an  exception. 

3  Code  Verification  Process 

Given  1)  source  code  annotated  with  Floyd-Hoare  pre¬ 
conditions  and  postconditions  and  2)  a  security  property  of 
interest,  the  problem  is  how  to  establish  that  the  code 
satisfies  the  property.  This  section  presents  a  five-step 
process  for  establishing  the  property,  each  step  producing 
one  of  the  five  artifacts.  The  five  steps  of  the  process  are 
listed  as  follows: 

1.  Formulate  a  TLS  of  the  code  as  a  state  machine 
model  in  the  style  of  [14],  [15]. 

2.  Formally  express  the  security  property  as  a  property 
of  the  state  machine  model.  Confirm  that  the 
property  is  preserved  under  refinement. 

3.  Translate  the  TLS  and  the  property  into  the  language 
of  a  mechanical  prover  and  prove  formally  that  the 
TLS  satisfies  the  property. 

4.  Given  source  code  annotated  with  preconditions 
and  postconditions,  partition  the  code  into  three 
categories — Event,  Other,  and  Trusted  Code — based 
on  some  criterion  determined  by  the  property  of 
interest. 

5.  To  demonstrate  that  the  Event  Code  does  not  violate 
the  property  of  interest,  construct  a)  a  mapping  from 
the  Event  Code  to  the  TLS  events  and  from  the  code 
states  to  the  states  in  the  TLS  and  b)  a  mapping  from 
the  preconditions  and  postconditions  of  the  TLS 
events  to  the  preconditions  and  postconditions  that 
annotate  the  corresponding  Event  Code.  Demon¬ 
strate  separately  that  Trusted  Code  and  Other  Code 
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are  benign.  Based  on  these  results,  conclude  that  the 
code  refines  the  TLS. 

Sections  3. 1-3.5  describe  how  the  above  process  was 
applied  to  the  annotated  code  which  implements  ED's 
separation  kernel.  Each  section  describes,  in  turn,  one  of  the 
five  artifacts  produced  for  ED.  For  the  security  property  of 
interest  in  ED,  that  is,  data  separation,  the  criterion  for 
partitioning  was  whether  the  code  touched  certain  Memory 
Areas  of  Interest  (MAIs).  Event  Code  corresponds  to  events  in 
the  TLS  that  touch  a  MAI,  Trusted  Code  touches  a  MAI  but  is 
not  Event  Code,  and  Other  Code  is  neither  Event  Code  nor 
Trusted  Code.  Section  3.4  precisely  defines  each  of  the  three 
code  categories.  To  provide  evidence  for  ED's  certification,  a 
logician  manually  annotated  the  kernel  code  with  assertions 
(that  is,  preconditions  and  postconditions)  as  a  basis  for 
validating  the  functional  correctness  of  the  code.  During  the 
certification  process,  evaluators  from  the  certifying  authority 
conducted  a  complete  code  walkthrough  of  the  annotated 
code  to  check  the  correctness  of  the  assertions.  Checking  that 
the  kernel  code  enforces  data  separation  uses  these  assertions 
in  Step  5. 

3.1  Top  Level  Specification 

Major  goals  of  the  TLS  are  to  provide  a  precise  yet 
understandable  description  of  the  allowed  security-relevant 
external  behavior  of  ED's  separation  kernel  and  to  make  the 
assumptions  on  which  the  TLS  is  based  explicit.1  To  achieve 
this,  the  TLS  of  the  kernel  behavior  is  represented  in  precise 
natural  language  as  a  state  machine  model  by  using  the 
style  of  the  Military  Message  System  (MMS)  security  model 
[14],  [15].  The  advantage  of  precise  natural  language  is  that 
it  enables  stakeholders  with  differing  backgrounds  and 
objectives,  that  is,  the  project  manager,  software  developers, 
evaluators,  and  the  formal  methods  team,  to  communicate 
precisely  about  the  required  kernel  behavior  and  helps 
ensure,  early  in  the  verification  process,  that  misunder¬ 
standings  are  weeded  out  and  issues  are  resolved.  Another 
goal  of  the  TLS  is  to  provide  a  formal  context  and  precise 
vocabulary  for  defining  data  separation. 

Like  the  secure  MMS  model,  the  state  machine  repre¬ 
senting  the  kernel  behavior  is  defined  in  terms  of  an  input 
alphabet,  a  set  of  states,  an  initial  state,  and  a  transform 
relation  describing  the  allowed  state  transitions.  The  input 
alphabet  contains  internal  and  external  events,  where  an 
internal  event  can  cause  the  kernel  to  invoke  some  process, 
and  an  external  event  is  performed  by  an  external  host.  The 
transform  (also  called  the  next-state  relation )  is  defined  on 
triples  consisting  of  an  event  in  the  input  alphabet,  the 
current  state,  and  the  new  state.  This  section  contains 
excerpts  from  the  TLS.  To  provide  intuition  about  the 
observable  kernel  behavior  of  ED,  it  also  describes  the  five 
internal  events  and  the  single  external  event  (the  last  event), 
listed  in  the  leftmost  column  of  Table  1. 

Partitions,  state  variables,  events,  and  states.  We 
assume  the  existence  of  n  >  1  dedicated  memory  partitions 
and  a  single  shared  memory  area.  We  also  assume  the 
existence  of  the  following  sets: 

1.  For  example,  the  assumptions  make  explicit  those  routines  that  the 
certification  authority  agreed  were  outside  the  scope  of  the  formal 
verification. 


TABLE  1 

Excerpts  from  the  Nonnull  Portion  of 
Access  Control  Matrix  AM  for  Partition  i,  1  <i<n 
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•  V  is  a  union  of  types,  where  each  type  is  a  nonempty 
set  of  values. 

•  R  is  a  set  of  state  variable  names.  For  all  r  in  R, 
TY(r)  C  V  is  the  set  of  possible  values  of  state 
variable  r. 

•  Ad  is  a  union  of  N  nonoverlapping  memory  areas, 
each  represented  by  a  state  variable. 

•  H  =  PU  E  is  a  set  of  M  events,  where  each  event  is 
either  an  internal  event  in  P  or  an  external  event  in  E. 

A  system  state  is  a  function  mapping  each  state  variable 
name  r  in  R  to  a  value.  Formally,  for  all  r  G  R,  s(r)  G  TY(r). 
Given  state  s  and  state  variable  r,  we  abbreviate  s(r)  by  rs. 

Memory  areas.  The  N  memory  areas  contain  N  —  1 
MAIs,  where  N  —  1  =  mn  and  m  is  the  number  of  MAIs  per 
partition.  Informally,  a  MAI  is  a  memory  area  containing 
data  whose  leakage  would  violate  data  separation.  The 
m  MAIs  for  a  partition  i,  1  <  i  <  n,  include  partition  i's 
input  and  output  buffers  and  k  data  areas  where  data  in 
partition  i  are  stored  and  processed.  The  Nth.  memory  area, 
called  G,  is  the  single  shared  memory  area  and  contains  all 
programs  and  data  not  residing  in  any  MAI.  The  set  Ad  of 
all  memory  areas  is  defined  as  the  union  4  U  {(?},  where 
A  =  {A{  j  |  1  <  i  <  n  A  1  <  j  <  m}  contains  the  mn  MAIs. 
For  all  i,  1  <  i  <  n,  A{  =  {Aj  j  |  1  <  j  <  m }  is  the  set  of 
memory  areas  for  partition  i.  To  ensure  that  they  are 
nonoverlapping,  the  memory  areas  of  Ad  are  required  to  be 
pairwise  disjoint. 

State  variables.  The  set  of  state  variables2  contained  in 
R  are 

•  a  partition  id  c, 

•  the  N  memory  areas  in  Ad,  and 

•  a  set  of  n  sanitization  vectors  W[l], . . . ,  W[n],  each 
vector  containing  k  elements. 

The  partition  id  c  is  0  if  no  data  processing  in  any  partition 
is  in  progress  and  it  is  i,  1  <  i  <  n,  if  data  processing  is  in 
progress  in  partition  i.  (Data  processing  can  occur  in  only 
one  partition  at  a  time.)  For  1  <  j  <  k,  the  Boolean  value  of 
the  jth  element  WJ[i]  of  the  sanitization  vector  for  partition  i 
is  true  initially  and  if  the  jth  memory  area  of  the 
ith  partition  has  been  sanitized  since  it  was  last  written, 
and  otherwise  false.  A  sanitized  memory  area  is  modeled  as 
having  the  value  0. 

Events.  The  set  of  internal  events  P  C  H  is  the  union  of 
n  sets,  P\, ,  Pn,  of  partition  events,  one  set  for  each 

2.  By  convention,  state  variable  names  may  refer  to  the  values  of  the 
variables. 
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partition  i,  and  a  singleton  set  Q.  Thus,  P  is  defined  by 
P  =  [Uf=1Pi]  U  Q.  Processing  occurs  on  partition  i  when  a 
sequence  of  events  from  Pi  is  processed.  The  first  four 
events  listed  in  Table  1  are  partition  events  in  some  Pi.  The 
first  event,  Begin_PartitionJ,  initiates  data  processing  in 
partition  i.  The  next  two  events  process  data  stored  in 
f's  memory  areas:  Event  Copy_BlIn_DlJ  copies  data  from 
B\,  which  is  an  input  buffer  assigned  to  i,  into  a  memory 
area  D\  of  i  and  event  Clear _D1J  sanitizes  memory  area  D\. 
The  event  EncLPartitionJ  concludes  data  processing  in 
partition  i.  Q's  sole  member  is  Other_NonPartProc, 
which  is  the  fifth  event  listed  in  Table  1,  an  abstract  event 
representing  all  internal  events  that  invoke  data  processing 
in  the  shared  memory  area  G.  An  example  is  the  event  that 
copies  a  shared  algorithm,  written  by  some  external  host 
into  a  shared  input  buffer,  to  some  other  part  of  G. 

The  set  of  external  events  E  c  H  is  defined  by 
E  =  Eln  U  E°ut  U  {Ext_Ev_Other},  where  Eln  =  \J}=lElf  and 

EOnt  =  \jn=iE Out.  Eln 

is  the  set  of  external  events  writing 
into  or  clearing  the  input  buffers  of  partition  i  and  E®ut  is 
the  set  of  external  events  reading  from  or  clearing  the 
output  buffers  of  partition  i.  The  event  Ext_Ev_Other 
represents  all  other  external  events.  ExtEv.BlInJ,  the  last 
event  listed  in  Table  1,  is  an  example  of  an  external  event  in 
Eln  which  occurs  when  an  external  host  writes  data  (to  be 
processed  in  partition  i )  into  the  input  buffer  B\. 

Partition  and  nonpartition  functions.  Operations  on 
data  in  partition  i,  for  example,  an  operation  copying 
data  from  one  MAI  in  partition  i  to  another  MAI  in  i,  are 
called  partition  functions.  For  all  i,  1  <  i  <  n,  and,  for  each 
internal  event  e  in  Pi,  there  exists  a  partition  function  Fe 
associated  with  e.  For  all  e  G  Pi,  Fe  has  the  signature 
re  :  TY(ai)  — >  TY(a2),  where  a\  and  a 2  are  MAIs  in  A*. 
Thus,  each  function  Te,  where  e  is  an  internal  event  in  Pi, 
takes  a  single  argument,  that  is,  the  value  stored  in  some 
MAI  a\  and  uses  that  argument  to  compute  a  value  to  be 
stored  in  MAI  a 2  as  the  result  of  event  e.  A  nonpartition 
function  Te  has  access  to  data  in  G  only. 

Access  control  matrix.  Associated  with  the  M  events  and 
N  memory  areas  is  an  M  by  N  access  control  matrix  AM, 
which  indicates  the  access  privileges  that  each  internal 
event  e  in  P  (and  its  associated  process)  and  each  external 
event  e  in  H  has  for  each  memory  area  a  in  M. .  The  access 
privileges  are  either  null  for  no  access,  R  for  read  access,  W 
for  write  access,  or  RW  for  both  read  and  write  access. 
Table  1  shows  excerpts  from  the  access  control  matrix  AM. 
The  leftmost  column  of  Table  1  lists  the  events  in  H  and  the 
headings  of  the  remaining  columns  list  memory  areas  in  M. . 
The  rightmost  column  heading  contains  G,  the  only  non- 
MAI,  while  the  remaining  column  headings  contain  all 
MAIs  for  partition  i.  For  all  i,  1  <  i  <  n,  AM  shows  the 
access  privileges  that  each  internal  and  external  event  has 
for  each  of  i's  memory  areas  and  for  memory  area  G.  In 
Table  1,  denotes  null  access.  For  all  i,j,  1  <  i,  j  <  n, 
i  f  j,  the  access  privilege  that  an  event  associated  with  i 
has  to  a  memory  area  associated  with  j  (not  shown  in 
Table  1)  is  null.  Similarly,  the  access  privilege  that  an 
event  associated  with  j  (not  shown  in  Table  1)  has  to  a 
memory  area  associated  with  i  is  also  null. 


To  illustrate  how  AM  limits  access  to  the  memory  areas  in 
M. ,  we  consider  the  event  in  the  second  row  of  Table  1,  that  is, 
e  =  Copy_BlIn_DlInJ.  Table  1  shows  that  a  process  invoked 
by  e  has  read  access  to  B\,  one  of  i's  input  buffers,  and  write 
access  to  D\,  one  of  i's  data  areas,  and  null  access  to  all  other 
memory  areas  in  M..  Thus,  for  event  e,  AM[e,Bl]  =  R, 
AM[e,  Z)l]  =  W,  and  AM[e,  a]  =  null  for  all  a,  a  G  M, 
a  {Bj,  Dj}.  Similarly,  the  event  Clear _D1J  can  only  write 
to  Dj  and  the  abstract  event  Other_NonPartProc  only  has  read 
and  write  access  to  G.  The  events  that  begin  and  end  data 
processing  on  i,  Begin_PartitionJ  and  End_PartitionJ, 
cannot  write  to  any  memory  area.  Finally,  the  external  event 
ExtEv_BlIn_z  invokes  a  process  that  can  only  read  and  write 
into  the  input  buffer  B\ . 

System.  A  system  is  a  state  machine  whose  transitions 
from  one  state  to  the  next  are  triggered  by  events.  Formally, 
a  system  E  is  a  4-tuple  E  =  (H,  S,  so,  T),  where 

•  H  is  the  set  of  events, 

•  S  is  the  set  of  states, 

•  sq  is  the  initial  state,  and 

•  T  is  the  system  transform,  a  partial  function  from 
H  x  S  into  S.  T  is  partial  because  not  all  events  are 
"enabled"  to  be  executed  in  the  current  state. 

Initial  state.  In  the  initial  state  so,  the  partition  id  c  is  0; 
for  all  z,  1  <  i  <  n,  the  MAIs  in  A;  are  0;  and  each  element  of 
the  sanitization  vectors  W[l] . . .  W[n]  is  true.  Hence,  in  the 
initial  state,  no  processing  in  any  partition  is  authorized, 
only  a  nonpartition  process  is  authorized  to  execute,  all 
MAIs  are  zero,  and  all  data  areas  are  known  to  be  sanitized. 

System  transform.  The  transform  T  is  defined  in  terms 
of  a  set  P  of  transform  rules  P  =  {Pe  \  e  E  H},  where  each 
transform  rule  Pe  describes  how  an  event  e  transforms  a 
current  state  into  a  new  state.  The  number  of  rules  is  M,  one 
rule  for  each  of  the  M  events  in  H.  No  rule  requires  access 
privileges  other  than  those  defined  by  the  access  control 
matrix  AM.  The  notation  s  and  s'  represents  the  current 
state  and  the  new  state,  respectively.  When  an  internal  or 
external  event  e  does  not  affect  the  value  of  any  state 
variable  r,  when  the  precondition  is  not  satisfied,  or  when 
the  event  e  is  not  enabled,  the  value  of  r  does  not  change 
from  state  s  to  state  s'  and  the  state  variable  r  retains  its 
current  value,  that  is,  rs  =  rs>. 

To  denote  that  no  state  variable  changes,  except  those 
explicitly  named,  we  write  NOC ^  (NO  Change,  except  to 
variables  in  R),  where  R  C  R.  This  notation  also  covers  the 
case  where  the  ith  element  of  a  sanitization  vector  changes, 
but  no  other  vector  elements  change.  For  example,  the 
postcondition  rhj=x  A  NOC{r},  where  x  G  TY(r),  is 
equivalent  to  rs>  =  x  A  \f  r  e  R,  r  f  r:  ry  =  rs. 

Suppose  that  s  is  a  state  in  S,  e  is  an  event  in  H,  and  R  is 
the  set  of  state  variables.  Let  prefi  be  a  state  predicate 
associated  with  e  such  that  pree  evaluates  to  true  if  e  has  the 
potential  to  occur  in  state  s  and  false  otherwise.  In  addition, 
let  poste  be  a  predicate  associated  with  e  such  that 
poste(s,  s')  holds  whenever  e  occurs  in  state  s  and  s'  is  a 
possible  poststate  of  s  when  event  e  occurs  in  state  s. 
Formally,  the  transform  rule  Pe  in  P  is  defined  by 

Pe  :  pree(s)  =>  poste(s,  s'). 

Whenever  the  result  state  of  every  event  e  is  deterministic 
(which  is  true  in  the  TLS  for  ED),  the  assertion  poste(s,  s') 
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defines  the  poststate  s'  =  T(e,  s).  To  make  T  total  on  H  x  S, 
the  complete  definition  of  T  is  written  as 

s',  if  pree(s),  where  poste(s,  s') 
s,  otherwise. 

In  the  above  definition,  pree(s)  is  not  satisfied  implies  that  e 
has  no  effect,  that  is,  essentially  e  does  not  occur.  Abstractly, 
this  models  raising  an  exception  and  halting. 

Examples  of  transform  rules.  For  all  i,  1  <  i  <  n,  the 
transform  rule  for  e  =  Begin_PartitionJ,  which  begins 
data  processing  on  i,  is  denoted  7^Begin_Partition_i-  A  precondi¬ 
tion  for  event  e  is  that  the  partition  id  is  0  (that  is,  the  system 
is  not  currently  processing  data  on  any  partition)  and  the 
postcondition  for  e  is  that  the  partition  id  is  i.  For  all  i, 
1  <  i  <n,  and,  for  all  states  s  and  s',  the  rule  1Ze  for  e  = 
Begin_PartitionJ  is  defined  by 

7^-Begin -Partitions  :  Cs  =  0  =t-  Cs>  =  i  A  NOC{c| . 

The  notation  NOCp.}  means  that  no  state  variable  other  than 
the  partition  id  c  can  change.  Similarly,  for  all  i,  1  <  i  <  n, 
the  rule  1ZC  for  e  =  EncLPartitionJ,  which  ends  data 
processing  on  i,  is  defined  by 

7^-End _ Partition _ i  •  Cs  —  'I  A  V  1  ^  J  ^  k,  Wg  [i]  —  tTll6 

=r-  cs>  =  0  A  NOC{c}. 

The  expression  "V  1  <  j  <  k,  WJs[i]  =  true"  in  the  above  rule 
means  that  each  element  of  the  sanitization  vector  for  i  must 
be  true  for  data  processing  on  i  to  end.  This  can  be  achieved 
by  invoking  clear  events  such  as  Clear _D1_«  prior  to  invoking 
End_PartitionJ.  The  purpose  of  this  precondition  is  to 
ensure  that  all  data  areas  of  partition  i  are  sanitized  prior  to 
processing  on  G,  on  partition  j,  j  /  i,  or  on  a  new 
configuration  of  i.  The  transform  rules  7?.Begm_Partition_i  and 
^End_Paxtitionj  are  the  only  rules  that  change  the  value  of  the 
partition  id  c.  Together,  these  rules  constrain  the  partition 
id  c  to  change  from  0  to  nonzero  or  from  nonzero  to  0. 

Processing  on  a  partition  i  can  include  copying  data  from 
an  input  buffer  of  partition  i  to  a  data  area  of  partition  i. 
Consider  again  the  internal  event  e  =  Copy_BlIn_DlInJ, 
whose  transform  rule  is  denoted  72.copy_Biin_Diinj-  The 
preconditions  for  e  are: 

(1)  The  partition  id  c  is  equal  to  i. 

(2)  The  invoked  process  must  have  read  access  R  for 
partition  i's  Input  Buffer  1  and  write  access  W  for 
Data  Area  1  in  partition  i. 

Postconditions  for  e  are: 

(3)  The  element  for  Data  Area  1  in  partition  i's 
sanitization  vector  becomes  false  (because  the  event 
stores  the  value  of  Buffer  1  in  Data  Area  1). 

(4)  A  function  of  the  value  in  partition  i's  Input  Buffer  1 
is  written  into  partition  i's  Data  Area  1. 

(5)  No  other  state  variable  changes. 

For  all  i,  the  rule  1Ze  for  event  e  =  Copy_BlIn_DlInJ  is 
defined  by 


^Copy_B  1  In_D  1  In_z  •  Cs  —  %  A 

(1) 

AM[e,  B\]  =  R  A  AM[e,  D}\ 

=  W  (2) 

=4>  Wj/  [i]  =  false  A 

(3) 

Dls/=Te(Bl)  A 

(4) 

NOC{vvi[*],Di}. 

(5) 

As  the  fourth  and  final  example  of  a 

transform 

rule,  consider  the  rule  for  the  internal  event 
e  =  Other_NonPartProc,  which  represents  all  nonpartition 
processing  events.  The  precondition  is  that  the  partition  id  c 
is  0  (that  is,  the  system  is  not  currently  processing  data  on 
any  partition).  The  effect  is  that  some  part  of  memory  area 
G  may  change.  The  rule  7 Ze  for  e  =  Other_NonPartProc  is 
defined  by 

P- O t her _N onP art P roc  •  —  0  A  AM[e,  G\  —  RW 

=>  Gy=re(Ga)A 

V  r  G  R,  r  /  G  :  tv  =  rs. 

3.2  Security  Property:  Data  Separation 

To  operate  securely,  ED  must  enforce  data  separation,  that 
is,  it  must  prevent  insecure  data  flows.  Informally,  this 
means  that  ED  must  prevent  data  in  a  partition  i  from 
influencing  or  being  influenced  by  1)  data  in  a  partition  j, 
where  i  f  j,  2)  data  in  an  earlier  configuration  of  partition  i, 
or  3)  data  stored  in  G.  To  demonstrate  that  the  TLS  enforces 
data  separation,  we  proved  that  it  satisfies  five  subproper¬ 
ties,  namely,  No-Exfiltration,  No-Infiltration,  Temporal  Separa¬ 
tion,  Separation  of  Control,  and  Kernel  Integrity.  Each 
subproperty  is  formally  defined  below  by  using  the 
notation  in  Section  3.1. 

3.2. 1  No-Exfiltration  Property 

The  No-Exfiltration  Property  states  that  data  processing  in 
any  partition  j  cannot  influence  data  stored  outside  the 
partition.  This  property  is  defined  in  terms  of  the  set  Aj  (the 
MAIs  of  partition  j);  the  entire  memory  Ai;  the  internal 
events  in  Pj,  which  invoke  data  processing  in  j;  and  the 
external  events  in  El 2 3 4 5f  U  £^ut,  which  affect  data  in  j's  input 
and  output  buffers. 

Property  3.1  (No-Exfiltration).  Suppose  that  states  s  and  s'  are 
in  state  set  S,  event  e  is  in  H,  memory  area  a  is  in  M,  and  j  is 
a  partition,  1  <  j  <  n.  Suppose  further  that  s'  =  T(e,  s).  If  e 
is  an  event  in  Pj  U  Elf  U  Ejut  and  as  f  as<,  then  a  is  in  Aj. 

3.2.2  No-Infiltration  Property 

The  No-Infiltration  Property  states  that  data  processing  in 
any  partition  i  is  not  influenced  by  data  outside  that 
partition.  It  is  defined  in  terms  of  the  set  Ai,  which  contains 
the  MAIs  of  partition  i. 

Property  3.2  (No-Infiltration).  Suppose  that  states  si,  S2,  s'v 

and  s'2  are  in  S,  event  e  is  in  H,  and  i  is  a  partition,  1  <  i  <  n. 
Suppose  further  that  Sj  =  T(e,  si)  and  s'2  =  T(e,  sf).  If,  for  all 
a  in  Ai,  aSl  =  aS2,  then,  for  all  a  in  Ai,  =  a^. 

3.2.3  Temporal  Separation  Property 

This  property  ensures  that  no  data  (for  example.  Top  Secret 
data)  stored  in  the  ith  partition  during  one  configuration  of 
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the  partition  can  remain  in  any  memory  area  of  a  later 
configuration  (for  example,  processing  Unclassified  data)  of 
that  same  partition  i.  The  property  is  guaranteed  if  the 
k  data  areas  in  any  partition  i  are  clear  when  the  system  is 
not  processing  data  in  that  partition,  for  example,  from  the 
end  of  a  processing  thread  in  one  partition  to  the  start  of  a 
new  processing  thread  in  the  same  or  a  different  partition.3 
The  set  of  states  in  which  the  system  is  not  processing  data 
stored  in  a  partition  is  exactly  the  set  of  states  in  which  the 
partition  id  c  is  0.  This  fact  is  used  in  stating  the  property. 

Property  3.3  (Temporal  Separation).  For  all  states  s  in  S,  for 

all  i,  1  <  i  <  n,  if  the  partition  id  cs  is  0,  then  the  k  data  areas 
of  partition  i  are  clear,  that  is,  D\s  =  0, . . . ,  =  0. 

3.2.4  Separation  of  Control  Property 

This  property  states  that,  when  data  processing  is  in  progress 
on  partition  i,  no  data  is  being  processed  on  partition  j,  j  f  i, 
until  processing  on  partition  i  terminates.  The  property  is 
defined  in  terms  of  the  partition  id  c  and  the  set  Dj  of  k  data 
areas  in  partition  i,  Dj  =  {D?  |  1  <  j  <  k}. 

Property  3.4  (Separation  of  Control).  Suppose  that  states  s 
and  s'  are  in  S,  event  e  is  in  H,  data  area  a  is  in  M,  and  j, 
where  1  <  j  <  n,  is  a  partition  id.  Suppose  further  that 
s'  =  T(e,  s).  If  neither  cs  nor  cs>  is  j,  then  as  =  a y  for  all 
a  e  Dj. 

3.2.5  Kernel  Integrity  Property 

The  Kernel  Integrity  Property  states  that,  when  data 
processing  is  in  progress  on  partition  i,  the  data  stored  on 
memory  area  G  does  not  change.  This  property  is  defined  in 
terms  of  G  and  the  set  Pi  of  events  for  partition  i. 

Property  3.5  (Kernel  Integrity).  Suppose  that  states  s  and  s' 
are  in  state  set  S,  event  e  is  in  H,  and  i  is  a  partition, 
1  <  i  <n.  Suppose  further  that  s'  =  T(e,  s).  If  e  is  a  partition 
event  in  Pir  then  Gs>  =  Gs. 

3.3  Formal  Verification 

To  formally  verify  that  the  TLS  enforces  data  separation,  the 
natural  language  formulation  of  the  TLS  was  translated  into 
TAME  (Timed  Automata  Modeling  Environment)  [16],  [17], 
a  front  end  to  the  mechanical  prover  PVS  [18]  which  helps  a 
user  specify  and  reason  formally  about  automata  models. 
This  translation  requires  the  completion  of  a  template  to 
define  the  initial  states,  state  transitions,  events,  and  other 
attributes  of  the  state  machine  E.  The  TAME  specification 
provides  a  machine  version  of  the  TLS  that  can  be  shown 
mechanically  to  satisfy  the  properties  defined  in  Section  3.2. 
After  constructing  the  TAME  specification  of  the  TLS,  we 
formulated  two  sets  of  TLS  properties  in  TAME  — invariant 
properties  and  other  properties — which  together  formalize 
the  five  subproperties.  Then,  for  each  set  of  properties,  we 
interactively  constructed  (TAME)  proofs  showing  that  the 
TAME  specification  satisfies  each  property.  The  scripts  of 
these  proofs,  which  are  saved  by  PVS,  can  be  rerun  easily  by 
the  evaluators  and  serve  as  the  formal  proofs  of  data 
separation.  One  benefit  of  TAME  is  that  the  saved  PVS 
proof  scripts  can  be  largely  understood  without  rerunning 
them  in  PVS. 

3.  The  proof  of  this  property  depends  on  the  constraint  noted  earlier:  If  c 
changes,  it  changes  from  0  to  nonzero  or  vice  versa. 


3.4  Partitioning  the  Code 

To  show  formally  that  the  separation  kernel  enforces  data 
separation,  we  must  prove  that  the  kernel  is  a  secure  partial 
instantiation  of  the  state  machine  E  defined  by  the  TLS.  The 
formal  verification  described  in  Section  3.3  establishes 
formally  that  a  strict  instantiation  of  the  TLS  enforces  data 
separation.  A  partial  instantiation  of  the  TLS  is  an  imple¬ 
mentation  that  contains  fine-grained  details  which  do  not 
correspond  to  the  state  machine  E  defined  in  the  TLS.  A 
secure  partial  instantiation  of  the  TLS  is  a  partial  instantiation 
of  the  TLS  in  which  the  fine-grained  details  that  do  not 
correspond  to  the  TLS  are  benign.  Section  4  contains  the 
formal  foundation  for  the  proof  that  the  code  is  a  secure 
partial  instantiation  of  the  TLS. 

The  proof  that  the  code  for  the  ED  kernel  is  a  secure 
partial  instantiation  of  the  TLS  is  based  on  a  demonstration 
that  all  kernel  code  falls  into  three  major  categories  and  one 
subcategory,  with  proofs  that  the  code  in  each  category 
satisfies  certain  properties.  The  categories  are  given  as 
follows: 

1.  Event  Code  is  kernel  code  that  implements  a  TLS 
internal  event  e  in  P  and  touches  one  or  more  MAIs. 
For  each  segment  of  Event  Code,  it  is  checked  that 

i.  the  concrete  translation  of  the  precondition  in 
the  TLS  for  the  corresponding  event  e  is  satisfied 
at  the  point  in  the  kernel  code  where  the 
execution  of  the  event  code  is  initiated,  and 

ii.  the  concrete  translation  of  the  postcondition  in 
the  TLS  for  the  corresponding  event  e  is  satisfied 
at  the  conclusion  of  Event  Code  execution. 

2.  Trusted  Code  is  kernel  code  that  touches  MAIs  but  is 
not  Event  Code.  This  code  does  not  correspond  to 
behavior  defined  by  the  TLS  and  may  have  read  and 
write  access  both  to  MAIs  and  to  memory  areas 
outside  the  MAIs.  It  is  validated  either  by  a  proof 
that  the  code  does  not  permit  any  nonsecure 
information  flows  or,  in  rare  instances,  by  external 
certification.  The  TLS  makes  explicit  any  assump¬ 
tions  used  in  connection  with  the  Trusted  Code  and 
its  behavior.  The  proofs  for  a  given  segment  of  the 
Trusted  Code  characterize  the  entire  functional 
behavior  of  that  Trusted  Code  by  using  Floyd-Hoare 
style  assertions  at  the  code  level  and  show  that  no 
nonsecure  information  flows  can  result  from  that 
code. 

3.  Other  Code  is  the  kernel  code  that  is  neither  Event 
Code  nor  Trusted  Code.  More  specifically,  Other 
Code  is  kernel  code  which  does  not  correspond  to 
any  behavior  defined  by  the  TLS  and  has  no  access 
to  any  MAI. 

a.  A  subset  of  the  Other  Code,  called  Validated  Code, 
is  code  with  no  access  to  MAIs  which  is  still 
security  relevant  because  it  performs  functions 
necessary  for  the  kernel  to  enforce  data  separa¬ 
tion.  These  functions  include  setting  up  the 
MMU,  establishing  preconditions  for  the  Event 
Code,  etc.  Floyd-Hoare  style  assertions  at  the  code 
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{CopyDIn_partition_id  :  partition  =  partitioned} 

{CopyDIn_priv  : 

{(R,  KER_I NBUFFER_l_par t i t i on) ,  (W,  KER_PAR_DATA_STORAGE_l_partition)}  C  MMU} 

{ CopyD In_value_dat a  :  Vj.O  <  j  <  byte_length. 

A[j]  =  KER_INBUFFER_l_part it ion_START  +  j} 

{CopyDIn_def_value_rest  :  Vj  .byte_length  <  j  <  KER_PAR_DATA_STORAGE_l_partition_SIZE. 

B[j]  =  KER_PAR_DATA_STORAGE_l_partition_START  +  j} 

{CopyDIn_local_inbuf f er  :  buf f er_in_start  =  KER_INBUFFER_l_partition_START} 
{CopyDIn_local_datain  :  part_data_start  =  KER_PAR_DATA_STORAGE_l_partition_START} 

if  (byte_length  <  (unsigned  long) & _ INBUFFER_SIZE) 

{ 

/*  copy  data  from  inbuffer  1  to  partition  */ 

/*  part_data_start  contains  the  starting  address  of  */ 

/*  the  memory  area,  buf fer_in_start  contains  */ 

/*  the  starting  address  of  the  inbuffer  */ 

/*  kerne l_memcopy  is  a  copy  routine  whose  functional  correctness  */ 

/*  has  been  verified  using  Floyd-Hoare  assertions  */ 

kerne l_memcopy (part_data_start,  buf fer_in_start,  byte_length) ; 

} 

{CopyDIn_copy_size_datain  :  byte_length  >  KER_PAR_DATA_STORAGE_partition_SIZE  — >  false } 
{ C opy D I n_c opy_s i z e_i nbuf f e r  :  byte_length  >  KER_INBUFFER_l_partition_SIZE  — >  false } 
{CopyDIn_gamma_copy  :  Vj.O  <  j  <  byte_length. 

KER_PAR_DATA_STORAGE_l_partition_START  +  j  =  A[j]} 

{CopyDIn_gamma_rest  :  Vj  .byte_length  <  j  <  KER_PAR_DATA_STORAGE_l_paxtition_SIZE. 

KER_PAR_DATA_STORAGE_l_part ition_START  +  j  =  B  [  j  ] } 

{CopyDIn_sanitize  :  part_datal_sanitized_partition  =  false} 

{CopyDIn_N0C  :  No  concrete  state  variables  have  changed  value  except  possibly 
KER_PAR_DATA_STORAGE_partition  and  part_datal_sanitized_partition. } 


Fig.  1.  Event  Code  and  code-level  assertions  for  the  event  Copy_B1ln_D1ln_i. 


level  are  used  to  prove  that  Validated  Code 
correctly  implements  the  required  functions. 

The  kernel  code  was  manually  partitioned  into  Event, 
Trusted,  and  Other  Code.  A  first  pass  through  the  code 
showed  that  only  a  small  number  of  functions  could  reset 
the  MMU  (that  is,  change  the  access  permissions  to  memory 
areas).  Apple's  Xcode  development  tool  [19]  was  used  to 
search  the  kernel  code  for  all  calls  to  these  functions.  Each 
such  call  was  inspected  to  determine  the  memory  areas  to 
which  access  was  granted.  By  analyzing  the  access  granted 
to  code  segments  categorized  as  Other  Code,  one  can  verify 
that  functions  called  in  these  code  segments  have  no  access 
to  any  MAI. 

Partitioning  the  code  in  this  manner  dramatically 
reduces  the  cost  of  code  verification  since  only  the  Event 
Code,  a  small  part  of  the  code,  needs  to  be  checked  for 
conformance  to  the  TLS.  In  ED,  Event  Code  and  Trusted 
Code  comprised  less  than  10  percent  of  the  code.  The 
remaining  90  percent  was  Other  Code. 

3.5  Demonstrating  Code  Conformance 

Demonstrating  that  the  kernel  code  conforms  to  the  TLS 
requires  the  definition  of  two  mappings.  To  establish 
correspondence  between  concrete  states  in  the  code  and 
abstract  states  in  the  TLS,  a  function  a  is  defined  which  relates 
concrete  states  to  abstract  states  by  relating  concrete  entities 
(such  as  memory  areas,  code  variables,  and  logical  variables) 
to  abstract  state  variables  in  the  TLS  (such  as  MAIs  and  the 
partition  id)  and  mapping  the  value  space  of  each  concrete 
entity  to  that  of  its  corresponding  abstract  state  variable.  For 
example,  a  maps  the  actual  physical  addresses  of  the  MAIs  to 
their  corresponding  abstract  state  variables  in  the  TLS.  In  the 
ED  kernel  code,  a  maps  a  global  variable  partitioned, 
corresponding  to  the  partition  id,  to  the  TLS  partition  id 


variable  c.  The  TLS  sanitization  vectors  have  no  analogs  in  the 
code.  Instead,  a  predicate  can  be  inferred  from  the  code  to 
indicate  whether  a  memory  area  is  sanitized.  To  represent 
sanitization  in  the  concrete  machine,  new  logical  variables 
(for  example,  part_datal_sanitized_z)  are  introduced,  and 
a  maps  these  variables  to  elements  of  the  sanitization 
vectors  in  the  TLS.  The  map  a  also  maps  the  Event  Code  to 
events  in  the  TLS.  Another  map  $  relates  assertions  at  the 
abstract  TLS  level  to  equivalent  assertions  at  the  code  level 
derived  from  the  abstract  assertions  and  the  map  a.  See 
Section  4  for  more  details. 

Using  4>  to  relate  preconditions  and  postconditions  for  an 
event  in  the  TLS  to  the  derived  preconditions  and  postcondi¬ 
tions  for  the  corresponding  Event  Code,  we  next  determine, 
for  each  piece  of  Event  Code,  sets  of  code-level  preconditions 
and  postconditions  that  match  the  derived  preconditions  and 
postconditions  as  closely  as  possible.  Fig.  1  shows  the  Event 
Code  corresponding  to  the  internal  event  Copy  _B  1  In_D  1  In  J  in 
the  TLS  (see  Section  3.1)  and  the  code-level  preconditions  and 
postconditions  for  this  Event  Code.  Although  the  Event  Code 
for  Copy_BlIn_DlInJ  consists  of  only  a  single  function  call, 
generally,  Event  Code  may  consist  of  any  block  of  code.  In 
Fig.  1,  the  top  box  contains  the  preconditions,  then  the 
indented  Event  Code  is  listed,  and,  finally,  the  bottom  box 
contains  the  postconditions.  Each  precondition  and  post¬ 
condition  has  the  form  (AssertionJIame  :  Assertion}. 
Generally,  the  match  between  assertions  in  the  TLS  and 
derived  code-level  assertions  is  not  exact  because  auxiliary 
assertions  are  added  (see  Fig.  1)  1)  to  express  the 
correspondence  between  variables  in  the  code  and  physical 
memory  areas4  (for  example,  CopyDIn_local_datain),  2)  to 
save  values  in  memory  areas  as  the  values  of  logical  variables 

4.  This  facilitates  Floyd-Hoare  reasoning  at  the  code  level. 
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TABLE  2 

Mapping  Preconditions  in  the  Code  to  Preconditions  in  the  TLS 


Precondition  <!>(  pree)(sc) 

Desired  in  the  Code 

Assertion  in 
Annotated  Code 

Precondition  pree(s) 
in  the  TLS 

Ref. 

No. 

Description 

CopyDIn_par t  i  t  i  on_id 

§8.4,  P5 

cs  —  i 

(1) 

Partition  id  is  i 

CopyDIn_priv 

§8.4,TLS1* 

AM(e,  B]  )  =  R 
AM(e,  D\  )  =  W 

(2) 

R  access  for  Input  Buffer  1, 

W  access  for  Data  Area  1 

CopyDIn_value_data 

§8.4, P4* 

B1 

- 

Value  of  data  in  Input  Buffer  1 

CopyDIn_def_value_rest 

§8.4,TLS4 

D1 

l,S 

- 

Value  of  Data  Area  1 

CopyDIn_local_inbuff er 

§8.4,  TLS3* 

- 

- 

Local  variable  for  Input  Buffer  1 

CopyDIn_local_datain 

§8.4,TLS2* 

- 

- 

Local  variable  for  Data  Area  1 

TABLE  3 

Mapping  Postconditions  in  the  Code  to  Postconditions  in  the  TLS 


Postcondition  <t,(poste)(sc,  s'c) 

Desired  in  the  Code 

Assertion  in 
Annotated  Code 

Postcondition  poste(s,s') 
in  the  TLS 

Ref. 

No. 

Description 

CopyDIn_copy_size_datain 

§8.4,R2* 

- 

- 

Wrong  size  — »  Error  return 

CopyDIn_copy_s ize_inbuf f  er 

§8.4,  R3* 

- 

- 

Wrong  size  — >  Error  return 

CopyDIn_gamma_copy 

CopyDIn_gaimna_rest 

§8.4,  R7* 
§8.4,TLS6 

d 1  ,  =  rmj  j 

l,s'  V  l,s' 

(4) 

Copy  to  Data  Area  1 

Rem  Data  Area  1  unchged 

CopyDIn_sanitize 

§8.4,TLS5* 

[i ]  =  false 

(3) 

Data  Area  1  not  sanitized 

CopyDIn_NOC 

By  inspection 

NOCfyyi^]^!} 

(5) 

No  other  change 

(for  example,  CopyDIn_value_data),  and  3)  to  express  error 
conditions  (for  example,  CopyDIn_copy_size_datain)  that  the 
TLS  abstracts  away  via  type  correctness.  The  derivation  of  the 
necessary  code-level  assertions  is  also  complicated  by  the 
code  itself.  For  example,  although  there  is  a  global  variable 
partition_id  in  the  code,  in  many  of  the  routines 
implementing  Event  Code,  the  partition  id  used  in  the 
routine  is  an  argument  that  is  passed  into  the  routine. 
This  results  in  a  code-level  precondition  asserting  that  the 
local  variable  for  the  partition  id  is  equal  to  the  global 
variable  partition_id  (for  example,  CopyDIn_partition_id 
in  Fig.  1). 

After  defining  the  desired  sets  of  code-level  preconditions 
and  postconditions,  we  check  whether  these  assertions  are 
among  the  assertions  already  proven  in  the  annotated  C 
code.5  The  annotated  C  code  often  refers  to  memory  areas  by 
indexing  into  arrays  that  define  memory  maps  in  the  code, 
whereas  the  mapping  a  refers  to  memory  areas  by  their  actual 
physical  addresses.  Thus,  to  be  equivalent  to  the  desired 
assertions,  the  assertions  in  the  annotated  code  frequently 
need  dereferencing.  For  example,  the  annotated  C  code 
assertion  §8.4,  TLS2  (see  Table  2)  is  defined  by 

part_data_start  = 

(uns  ignedchar  * )  ke  r_r  t  ime_minu_map  [par  t  i  t  i  on] .  par  t_dat  a_s  t  art , 

which  sets  the  variable  part _data_s tart  to  the  starting 
address  of  the  data  area  in  the  partition  by  indexing  into  the 
real-time  memory  map  in  the  code  and  selecting  the 
part_data_start  member  of  the  structure  corresponding 
to  that  array  element.  Dereferencing  the  index  into  the 
array  and  pointer  into  the  structure  yields  the  memory 
area  KER_PARJDATA_STORAGE_l_partition_START,  the  actual 

5.  In  general,  the  annotated  code  contains  significantly  more  assertions 
than  are  needed  to  show  correspondence  because  the  annotations  were 
primarily  designed  to  show  the  functional  correctness  of  the  code. 


physical  address  of  the  partition  data  area,  which  stores 
the  value  used  in  the  code-level  precondition 
CopyDIn_local_datain  (see  the  last  line  of  the  top  box 
in  Fig.  1). 

In  our  initial  attempt  to  match  a  precondition  and 
postcondition  in  the  annotated  C  code  with  each  desired 
precondition  and  postcondition,  either 

•  the  desired  assertion  exactly  matched  an  assertion  in 
the  annotated  code, 

•  the  desired  assertion  exactly  matched  an  assertion 
in  the  annotated  code,  except  dereferencing  was 
required, 

•  the  desired  assertion  was  a  close  but  not  exact  match 
of  an  assertion  in  the  annotated  code,  or 

•  no  code  assertion  exactly  or  approximately  matched 
the  desired  assertion. 

We  worked  with  the  logician  who  annotated  the  C  code  to 
ensure  that  assertions  corresponding  to  all  of  the  desired 
preconditions  and  postconditions  were  added  to  and  verified 
on  the  code.  (In  general,  it  is  sufficient  to  include  strongest 
postconditions  implying  our  derived  assertions.)  For  exam¬ 
ple,  assertions  about  a  predicate  SANITIZED  on  memory  areas 
were  added  to  the  annotated  code  to  provide  correspon¬ 
dence  to  the  necessary  code-level  assertions  about  the 
sanitization  of  memory  areas.  To  show  correspondence 
between  the  preconditions  and  postconditions  in  the  code 
and  the  TLS,  two  tables  were  created  for  each  TLS  event. 
Tables  2  and  3  are  the  correspondence  tables  for  the 
preconditions  and  postconditions  of  the  transform  rule  for 
the  TLS  event  Copy_BlIn_DlIn.  In  the  tables,  s  and  s'  = 
T(e,  s)  represent  the  abstract  prestate  and  poststate,  sc  and 
s'c  represent  the  concrete  prestate  and  poststate,  and  4>, 
which  is  formally  defined  in  Section  4,  maps  abstract 
predicates  to  corresponding  concrete  predicates. 
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In  Tables  2  and  3,  the  first  column  contains  the  label  of  a 
desired  code-level  precondition  or  postcondition  from 
Fig.  1,  the  second  column  gives  the  location  (the  section 
number  and  assertion  label)  of  the  corresponding  assertion 
in  the  annotated  C  code,  the  third  column  contains  the 
corresponding  precondition  or  postcondition  (if  any)  in  the 
TLS,  the  fourth  column  gives  the  reference  number  of  the 
corresponding  assertion  in  the  transform  rule,  and  the  fifth 
column  briefly  describes  the  assertion.  In  cases  where  no 
corresponding  assertion  exists  in  the  TLS,  appears  in 
both  the  third  and  fourth  columns.  An  asterisk  in  the 
second  column  indicates  that,  for  equivalence  between  the 
assertion  in  the  annotated  code  and  the  desired  code 
assertion  to  hold,  the  assertion  in  the  annotated  code 
requires  dereferencing. 

Tables  2  and  3  show  that,  for  every  precondition  and 
postcondition  of  CopyBlIn_DlInJ,  there  is  an  equivalent 
precondition  or  postcondition  in  the  annotated  code.  There¬ 
fore,  we  have  shown  that,  for  CopyBlIn_DlInJ,  the  full 
code-level  preconditions  and  postconditions  imply  the  TLS 
preconditions  and  postconditions.  Using  the  same  techni¬ 
ques,  we  have  also  demonstrated  the  analogous  result  for 
the  remaining  events.  As  shown  in  Section  4,  this  demon¬ 
strates  that  the  Event  Code  implementing  the  separation 
kernel  is  a  refinement  of  the  TLS. 

4  Formal  Foundations 

Section  4.1  adapts  the  classical  theory  of  refinement  [10],  a 
technique  for  proving  that  a  concrete  state  machine  model 
conforms  to  (that  is,  is  a  refinement  of)  an  abstract  state 
machine  model,  into  a  form  that  we  can  use  to  show  that  the 
behavior  of  the  kernel  code  conforms  to  the  behavior 
captured  in  the  TLS.  Section  4.1  also  covers  the  formal 
foundation  for  our  method  of  proving  refinement  and 
describes  how  we  have  applied  it  to  verify  that  the  kernel 
code  correctly  implements  the  TLS.  The  refinement  proof 
technique  that  we  use  is  closed  under  iteration  (see 
Appendix  A  for  the  formal  statement  and  proof).  Section  4.2 
compares  our  use  of  refinement  relations  and  our  method  of 
verifying  them  with  other  techniques  for  applying  and 
proving  refinements. 

4.1  Adapting  the  Classical  Theory  of  Refinement 

To  begin,  a  function  a  is  defined  which  maps  each  concrete 
state  at  the  code  level  to  a  corresponding  abstract  state  in 
the  TLS  state  machine  E  by  relating  variables  at  the  concrete 
code  level  to  variables  at  the  abstract  TLS  level.  Variables  at 
the  concrete  level  include  variables  in  the  code,  predicates 
defined  on  the  code,  logical  history  variables,  and  memory 
areas.  Among  the  most  important  memory  areas  treated  as 
concrete  state  variables  are  the  data  areas  and  the  input  and 
output  buffers  assigned  to  each  partition,  all  of  which  are 
central  to  reasoning  about  possible  information  flows. 
Provided  each  possible  value  of  a  concrete  state  variable 
can  be  represented  by  some  possible  value  of  the 
corresponding  abstract  state  variable  (as  is  true  for  ED), 
the  map  a  from  concrete  to  abstract  state  variables  induces  a 
map  ct :  5C  — >  5a  from  concrete  to  abstract  states  in  the 


Postea(5a,ea(5a)) 
0(Postea)(jc,  ec(5c)) 

I 

Postec(5c,ec(sc)) 


Fig.  2.  Relations  to  establish  between  concrete  and  abstract  transitions 
and  preconditions  and  postconditions. 


obvious  way.6  Once  a  is  defined  at  the  level  of  states  in 
terms  of  state  variables  and  their  values,  the  set  Ec  of  Event 
Code  segments  is  identified,  and  a  is  extended  to  map  each 
code  segment  ec  in  Ec  to  a  corresponding  internal  event 
ea  =  ct(ec)  in  the  TLS.7 

The  map  a  from  concrete  states  to  abstract  states 
provides  a  means  of  taking  any  predicate  Pa  :  5a  — >  Bool 
on  abstract  states  and  deriving  a  corresponding  predicate 
<3>(Pa)  :  5C  — >  Bool  on  concrete  states  as  follows: 

5-(Pa)(Sc)=Pa(a(Sc)), 

where  sc  is  any  state  in  5C.  Analogously,  a  can  be  used  to 
derive  a  predicate  4»(Pa)  :  5C  x  5C  — >  Bool  on  pairs  of 
concrete  states  from  a  predicate  on  pairs  of  abstract  states 
as  follows: 

$(Pa)(Sc>Sc)  =  PaMsJ),a(Sc))> 

where  s*  and  are  any  states  in  5C.  The  map  is  used  to 
relate  preconditions  and  postconditions  in  the  code  to 
preconditions  and  postconditions  in  the  TLS  (see  Fig.  2). 
Note  that  preconditions  (at  both  levels)  apply  only  to  one 
state.  To  capture  the  fact  that  an  event  changes  only  certain 
state  variables  (indicated  at  the  abstract  level  by  the 
notation  NOC),  the  postconditions  are  represented  at  both 
levels  as  predicates  on  two  states. 

In  Fig.  2,  we  follow  the  convention  of  representing  a(sc) 
by  sa.  Note  that,  although  the  preconditions  and  postcondi¬ 
tions  on  the  concrete  and  abstract  transitions  in  Fig.  2  are 
denoted  analogously,  their  required  relationships  to  their 
corresponding  transitions  differ.  In  particular,  the  precon¬ 
dition  Preea(sa)  is  a  guard  that,  when  false,  prevents  ea  from 
firing,  while  the  precondition  Preec(sc)  is  simply  an 
assertion  known  to  hold  before  ec  fires.  Moreover,  the 
postcondition  Postea(sa,  ea(sa))  is  intended  to  capture  the 
effect  of  the  action  ea  on  the  state  sa,  while  the  postcondition 
Postec(sc,  ec(sc))  is  simply  an  assertion  known  to  hold  for 
the  states  before  and  after  ec  fires.  Hence,  the  requirements 
for  the  abstract  preconditions  and  postconditions  fulfill  the 
requirements  for  concrete  preconditions  and  postconditions 
(but  not  vice  versa).  Thus,  in  our  refinement  proof  method 


6.  To  distinguish  abstract  from  concrete  entities,  this  section  tags  abstract 
entities  with  an  a  and  concrete  entities  with  a  c.  For  example,  Sa  represents 
the  abstract  states  and  Sc  represents  the  concrete  states. 

7.  When  external  events,  which  have  no  corresponding  event  code,  can 
occur  in  a  system  (as  is  true  in  the  ED  kernel),  a  must  be  similarly  extended 
to  map  these  "concrete"  external  events  to  their  abstract  equivalents.  At  both 
levels,  the  preconditions  of  external  events  are  true  and  their  postconditions 
capture  their  effects. 
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below,  an  abstract  TLS  can  play  a  role  analogous  to  concrete 
code  with  respect  to  a  still  more  abstract  TLS.  For  details, 
see  Appendix  B. 

To  establish  equivalence  between  the  behavior  of  the 
kernel  code  and  a  subset  of  the  behavior  modeled  in  the 
TLS,  it  is  sufficient  to  prove,  in  the  simplest  case,  that,  for 
every  ec  in  Ec,  the  following  conditions  hold: 

1.  Whenever  the  concrete  code  segment  ec  is  ready  to 
execute  in  state  sc,  some  concrete  precondition  Preec 
holds,  where  Preec  implies  4>(Preea),  the  concrete 
precondition  derived  from  the  abstract  precondition 

for  ea  =  a(ec). 

2.  Whenever  the  concrete  precondition  PreCc  holds  for 
the  current  program  state  sc,  some  concrete  post¬ 
condition  Postec  holds  for  the  pair  of  program  states 
(sc,  ec(sc))  immediately  before  and  immediately  after 
the  execution  of  ec,  where  Poste<;  implies  4>(Postea), 
the  concrete  postcondition  derived  from  the  abstract 
postcondition  for  ea. 

3.  The  diagram  in  Fig.  2  commutes  whenever  PreCc(sc) 
holds. 

Although  this  method  requires  the  proof  of  conditions  1,  2, 
and  3,  it  is  essentially  condition  3  that  is  needed  for  a  to  be  a 
refinement  mapping.  To  prove  condition  3,  it  is  normally 
sufficient  to  prove  conditions  1  and  2. 

Theorem  4.1.  Provided  Vs,  s'  £  S&  :  Pre6a(s)  ==>  [Postea(s,  s')  = 
(s'  =  ea(s))]  (this  holds  for  poste  in  the  TLS  transform 
described  in  Section  3.1),  conditions  1  and  2  imply  condition  3. 

Proof.  By  hypothesis,  we  know  that 

(i)  Vs,  s'  £  5a  :  Preea(s)  =>  [Postea(s,  s')  =  (s'  =  ea(s))] 

and  may  assume  that  conditions  1  and  2  hold.  Further, 
by  the  hypothesis  of  condition  3,  we  may  also  assume 
that 

(ii)  PreCc(sc). 

By  condition  1,  it  follows  from  (ii)  that  4>(Preea)(sc), 
which  means,  by  the  definition  of  4>,  that 

(iii)  Preea(Q;(sc)). 

Furthermore,  by  condition  2,  we  have 

(iv)  Preec(sc)  =>  PostCc(sc, ec(sc)), 

and 

(v)  Postec(sc,ec(sc))  =>  4>(Postea)(sc,ec(sc)). 

Thus, 


Preec(sc) 

P  ostCc  ( sc ,  ec  ( sc) ) 

=>  $(Postea)(sc,ec(sc)) 

«=>  Post  eft(a(sc),a(ec(sc))) 
a(ec(«c))  =  ea(a(sc)) 


(by  (ii)) 

(by  (iv)) 

(by  (v)) 

(by  the  definition  of  4>) 
(by  (i)  and  (iii)). 


But,  the  last  assertion  means  that  the  diagram  in  Fig.  2 
commutes,  which  is  the  conclusion  of  condition  3.  □ 

The  hypothesis  of  Theorem  4.1  does  not  truly  limit  its 
use,  provided  that  the  abstract  postcondition  exactly 
captures  all  possible  effects  of  the  abstract  transition.  In 
particular,  suppose  that  the  definition  of  the  abstract 


transition  allows  nondeterminism,  and  that  one  has  estab¬ 
lished,  based  on  conditions  1  and  2  and  the  hypothesis  of 
condition  3,  that  Postea(o:(sc),  ct(ec(sc))),  that  is,  that 
Postea(sa,  a(ec(sc))).  Then,  to  fulfill  the  hypothesis  of 
Theorem  4.1,  one  can  simply  replace  ea  by  its  deterministic 
instance  for  which  the  abstract  poststate  ea(sa)  is  a(ec(sc)). 

Establishing  conditions  1-3  guarantees  that,  whenever 
the  code  segment  ec  executes  in  the  code,  there  is  an  enabled 
event  ea  in  the  TLS  that  causes  a  transition  from  the  abstract 
image  sa  under  a  of  the  concrete  prestate  sc  at  the  code  level 
into  an  abstract  state  ea(sa)  that  is  the  abstract  image  under 
a  of  the  concrete  poststate  ec(sc)  at  the  code  level.  More 
concisely,  conditions  1,  2,  and  3  imply  that  there  exists  an 
abstract  transition  that  models  the  concrete  transition. 

The  relation  of  Event  Code  segments  to  abstract  events 
can  be  slightly  more  complex  than  shown  in  Fig.  2.  For 
example,  in  some  cases,  ec  may  implement  more  than  one 
event.  However,  these  more  complex  cases  can  usually  be 
handled  similarly.  When  a  concrete  event  implements 
n  abstract  events,  for  example,  one  looks  for  a  partition 
Prec  =  PreJ  ©  ...  ©  Pre”  of  the  concrete  precondition  Prec 
such  that,  when  the  zth  part  Pre*  holds,  the  code  ec 
implements  the  zth  abstract  event.  Then,  one  establishes, 
for  each  i,  a  commutative  diagram  analogous  to  the 
diagram  in  Fig.  2. 

The  argument  that  the  kernel  code  of  ED  ensures  data 
separation  is  based  on  relating  executions  of  the  code  to 
executions  in  the  TLS.  To  begin,  we  observe  that  a  maps 
ED's  initial  state  via  a  to  an  allowed  initial  state  in  the  TLS. 
To  support  the  remainder  of  the  argument,  the  Event  Code 
set  Ec  and  the  code-level  map  a  are  extended  to  cover  the 
Other  Code.  Most  Event  Code  segments  consist  of  a  single 
program  statement.  In  contrast.  Other  Code  contains  many 
lengthy  code  segments  which  simply  manipulate  local 
variables  inside  a  function  or  procedure  and  do  not  map 
to  any  abstract  event.  Such  segments  typically  occur  prior  to 
an  Event  Code  segment.  We  model  these  Other  Code 
segments  at  the  abstract  level  by  a  no-op  ("do  nothing") 
event  implicitly  included  in  the  TLS.  It  is  possible  to  map 
the  effect  of  a  segment  of  the  Other  Code  to  a  no-op  in  the 
TLS  because,  unlike  Event  and  Trusted  Code,  the  Other 
Code  has  no  access  to  MAIs.  Because  every  code  segment  in 
the  Event  or  Other  Code  is  modeled  either  by  an  abstract 
TLS  event  with  concrete  and  abstract  transitions  related  as 
in  Fig.  2  or  by  a  no-op  in  the  TLS,  it  follows  that  every 
execution  of  this  part  of  the  code  corresponds  to  an 
execution  in  the  TLS. 

Trusted  Code  in  the  ED  kernel  can  be  related  to  the  TLS 
as  follows:  First,  it  is  established  that  no  segment  of  the 
Trusted  Code  causes  insecure  data  flows.  Some  segments  of 
the  Trusted  Code  have  been  verified,  and  the  remaining 
segments  have  been  certified  externally  to  cause  no  insecure 
information  flows.  The  state  change  caused  by  each  Trusted 
Code  segment  is  then  shown  to  map  to  the  result  of  either  a 
no-op  in  the  TLS  or  some  sequence  of  events  in  the  TLS.  In 
the  overall  argument  that  an  execution  of  concrete  code 
always  maps  to  a  possible  execution  in  the  TLS,  each 
Trusted  Code  segment  is  treated  as  an  indivisible  unit.  In 
ED,  this  is  possible  because  each  Trusted  Code  segment 
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executes  within  a  single  partition  and  executions  within  a 
partition  are  never  interrupted. 

Combining  this  reasoning  with  the  additional  assurance 
that  a  relates  concrete  data  and  buffer  memory  areas  to 
abstract  ones  and  thus  models  all  information  flows 
involving  MAIs,  it  follows  that  all  kernel  behavior  relevant 
to  data  separation  at  the  concrete  level  is  modeled  at  the 
abstract  level.  Thus,  the  Data  Separation  Property  proven  at 
the  abstract  level  also  holds  at  the  concrete  level. 

4.2  Uses  and  Proof  Methods  for  Refinement 

Although  some  details  of  how  they  are  applied  may  vary, 
commutative  diagrams  are  widely  used  to  describe  the 
required  relationships  between  transitions  at  the  concrete 
and  abstract  levels  in  a  refinement  relation  (sometimes 
referred  to  as  an  abstraction  relation). 

When  model  checking  is  used  to  verify  systems,  a  typical 
approach  is  to  generate  an  abstract  model  automatically 
using  data  abstraction  [20]  or  data  type  reduction  [21]  in  a 
way  that  guarantees  that  the  original  system  is  a  refinement 
of  the  model.  Thus,  any  properties  verified  of  the  abstract 
model  that  are  preserved  under  refinement  will  also  hold 
for  the  system.  In  this  approach,  refinement  is  a  given  and 
need  not  be  proved.  For  us,  it  was  not  feasible  to  use  model 
checking  to  produce  an  abstract  model.  Due  to  the  state 
explosion  problem,  model  checking  for  verification  has 
mostly  been  applied  to  hardware  systems.  Although,  to 
some  extent,  methods  such  as  abstraction  refinement  [22] 
have  made  it  more  feasible  to  apply  model  checking  to 
software  systems,  model  checking  is  better  for  detecting 
software  bugs  than  for  verifying  software. 

The  concept  of  refinement  also  arises  in  the  context  of 
proving  an  implementation  relation  from  a  more  concrete 
system  model  to  a  more  abstract  one.  For  example,  Burch 
and  Dill  [23]  use  decision  procedures  and  Cyrluk  [24]  uses 
PVS  to  verify  that  concrete  models  implement  specifications 
by  proving  that  a  set  of  diagrams  commute,  where  the 
diagram  for  each  transition  captures  the  correlation 
between  sequences  of  instructions  at  the  concrete  and 
abstract  levels.  McMillan  [21]  avoids  this  use  of  commu¬ 
tative  diagrams  by  using  compositional  model  checking  for 
proving  implementation,  in  particular  by  model  checking 
individual  transitions  separately  and  then  proving  that  the 
results  compose.  In  the  context  of  hierarchical  verification, 
Robinson  and  Levitt  [25]  use  a  diagram  that  relates  concrete 
states  to  abstract  states  and  concrete  programs  (or  program 
fragments)  to  abstract  transitions  in  which  the  poststate  is 
mathematically  defined  in  terms  of  the  prestate.  The 
abstraction  mappings  of  Robinson  and  Levitt,  as  well  as 
those  of  Burch  and  Dill  and  of  Cyrluk,  differ  from  ours  in  that 
they  require  the  mapping  to  be  a  surjection,  whereas  we 
instead  require  it  to  be  total.  These  authors'  condition  for 
implementation  correctness  is,  like  ours,  that  the  diagram 
must  commute.  The  surjection-versus-total  difference  reflects 
our  different  use  of  abstraction:  They  wish  to  prove  that  a 
more  concrete  program  fully  implements  its  abstraction, 
whereas  we  wish  to  deduce  the  correctness  of  the  concrete 
program  from  the  correctness  of  the  abstraction. 

We  also  add  a  method  for  proving  that  a  program  (or 
program  fragment)  implements  an  abstract  transition  by 
proving  certain  relationships  among  preconditions  and 


postconditions  at  the  concrete  and  abstract  levels.  Fig.  2 
shows  these  required  relationships,  along  with  the  commu¬ 
tative  diagram.  We  also  make  explicit  that  1)  at  the  state 
variable  level,  the  "state  variables"  mapped  by  the  mapping 
function  can  be  derived  variables  or  logical  variables  that, 
for  example,  capture  history  and  2)  postconditions  are 
actually  predicates  on  two  states.  Thus,  we  are  able  to 
handle  state  and  transition  information  for  which  Abadi 
and  Lamport  [10]  use  history  and  prophecy  variables. 

5  Discussion 

5.1  Applying  Our  Techniques  to  Other  Security 
Properties 

This  section  considers  the  class  of  security  properties  that 
can  be  verified  using  the  techniques  and  formalization 
described  in  Sections  3  and  4.  Two  important  classes  of 
security  properties  are  safety  and  liveness.  In  [26],  Alpern 
and  Schneider  formally  define  safety  and  liveness,  conclud¬ 
ing  that  any  property  p  can  be  expressed  as  the  intersection 
of  a  safety  property  and  a  liveness  property.  Informally,  a 
safety  property  states  that  nothing  "bad"  happens  during 
execution  and  a  liveness  property  states  that  something 
"good"  happens  during  execution  [27].  For  Alpern  and 
Schneider,  a  set  of  executions  is  called  a  property  if 
membership  in  the  set  is  determined  by  each  execution 
alone,  without  reference  to  other  executions  in  the  set. 
McLean  has  identified  a  serious  limitation  of  this  notion  of 
property — not  every  security  property  of  interest  is  a 
property  of  executions  [28] — and  presents  Noninterference 
as  an  example  [29]  of  a  property  of  sets  of  executions  rather 
than  a  property  of  executions. 

For  the  techniques  presented  in  Section  3  to  apply,  a 
security  property  p  must  be  preserved  under  refinement.  It  is 
well  known  that  safety  properties  are  preserved  under 
refinement  but  that  liveness  properties  are  not  [10].  More¬ 
over,  McLean  has  shown  that  properties  such  as  Noninter¬ 
ference  are  not  preserved  by  refinement  [30].  Hence,  our 
techniques  can  be  used  to  guarantee  security  properties  that 
are  safety  properties.  It  is  easy  to  show  that  four  of  the  security 
properties  defined  in  Section  3.2 — No-Exfiltration,  Temporal 
Separation,  Separation  of  Control,  and  Kernel  Integrity — are 
safety  properties.  Therefore,  all  four  properties  are  preserved 
by  refinement.  The  fifth  property,  No-Infiltration,  is  not  a 
safety  property  because  it  is  not  a  property  of  executions  but  a 
property  of  sets  of  executions.  However,  it  is  easily  shown  to 
be  preserved  under  refinement. 

Our  approach  may  be  applied  to  many  applications  that, 
like  ED,  enforce  access  control.  Applications  that  enforce 
access  control  restrict  the  operations  that  subjects  (for 
example,  users)  can  perform  on  objects  (for  example,  data). 
As  long  as  the  access  control  policy  can  be  represented  as  a 
safety  property,  our  approach  applies.  A  second  important 
class  of  applications  to  which  our  approach  applies  are  those 
described  by  Schneider,  which  use  Execution  Monitoring 
(EM)  to  enforce  security  [31].  Examples  of  EM  mechanisms 
are  reference  monitors,  firewalls,  and  other  operating  system 
and  hardware-based  enforcement  mechanisms  described  in 
the  literature.  Excluded  from  this  class  are  applications 
that  use  more  information  than  would  be  available  from 
observing  only  the  states  of  a  single  system  execution. 
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Schneider  shows  that  the  security  properties  enforced  by 
EM  mechanisms  are  safety  properties. 

5.2  Applying  Our  Method  to  Additional  Kernel 
Properties 

In  ED's  certification,  our  task  was  to  develop  a  TLS  of  ED's 
kernel  code,  to  verify  that  the  TLS  satisfies  data  separation, 
and,  finally,  to  demonstrate  conformance  of  the  kernel  code  to 
the  TLS.  An  important  aspect  of  our  approach  is  that,  if 
required,  we  can  construct  a  refinement  of  the  TLS  by  adding 
new  variables  and  events  to  the  TLS  to  capture  some  behavior 
of  (that  is,  events  in)  the  Other  Code.  If  the  security  properties 
that  we  wish  to  prove  about  this  additional  behavior  are 
preserved  by  refinement,  then  we  can  formally  state  and 
prove  the  new  security  properties  for  the  refinement  of  the 
TLS  and  show  correspondence  between  the  related  portion  of 
the  Other  Code  and  the  new  behavior.  Because  our  proof 
method  can  be  iterated  through  a  series  of  refinements  (see 
Appendix  A),  the  proof  of  data  separation  remains  valid 
under  such  a  refinement  of  the  TLS. 

6  Lessons  Learned 

6.1  Software  Design  Decisions 

Three  software  design  decisions  were  critical  in  making 
code  verification  feasible.  One  major  decision  was  to  use  a 
separation  kernel,  a  single  software  module  to  mediate  all 
memory  accesses.  A  design  that  distributed  the  checking  of 
memory  accesses  would  have  made  the  task  of  proving  data 
separation  much  more  difficult.  A  second  critical  decision 
was  to  keep  the  software  simple.  For  example,  once 
initiated,  data  processing  in  a  partition  was  run  to 
completion  unless  an  exception  occurred.  In  addition,  ED's 
services  were  limited  to  the  essential  ones:  The  temptation 
to  add  new  services  late  in  the  development  was  resisted. 
The  third  critical  decision  was  enforcing  "least  privilege." 
For  example,  if  a  process  only  requires  read  access  to  a 
memory  area,  the  kernel  only  grants  read,  not  read  and 
write,  access. 

6.2  Top-Level  Specification 

One  significant  challenge  was  to  understand  the  exter¬ 
nally  visible  security-relevant  behavior  of  the  separation 
kernel.  Both  scenarios  and  the  SCR  (Software  Cost 
Reduction)  tools  [32],  [33]  were  useful  in  extending  our 
understanding  of  the  kernel  behavior.  To  begin,  we 
formulated  several  scenarios,  that  is,  sequences  of  events, 
and  specified  the  kernel  response  to  those  events.  After 
specifying  a  state  machine  model  of  the  kernel  in  SCR, 
we  ran  the  scenarios  through  the  SCR  simulator.  As 
expected,  formulating  the  scenarios  and  running  them 
through  the  simulator  exposed  gaps  in  our  understand¬ 
ing.  Both  the  scenarios  and  the  questions  raised  were 
valuable  in  eliciting  details  of  the  security-relevant  kernel 
behavior  from  ED's  development  team. 

Once  the  kernel's  required  behavior  was  understood, 
approximately  2.5  weeks  were  needed  to  formulate  the  TLS 
and  the  data  separation  property.  The  complete  statement 
of  the  TLS,  including  the  assumptions,  is  only  15  pages 
long.  Keeping  the  size  of  the  TLS  small  was  critical  for  many 
reasons.  It  simplified  communication  with  the  other 


stakeholders,  changing  the  specification  when  the  kernel 
behavior  changed,  translating  the  specification  into  TAME, 
and  proving  that  the  TLS  enforced  data  separation. 

During  the  certification  process,  the  natural  language 
representation  of  the  TLS  enabled  stakeholders  with 
differing  backgrounds  and  objectives — for  example,  the 
project  manager  and  the  evaluators — to  communicate  easily 
with  the  formal  methods  team  about  the  kernel's  required 
behavior.  Discussion  among  the  various  stakeholders 
helped  ensure  that  misunderstandings  were  avoided  and 
issues  were  resolved  early  in  the  certification  process.  This 
natural  language  representation  of  the  TLS  for  ED  contrasts 
with  the  representations  used  in  many  other  formal 
specifications  of  secure  systems,  which  are  often  expressed 
in  specialized  languages  such  as  ACL2  (for  example,  see 
[34]).  Moreover,  any  ambiguity  inherent  in  the  natural 
language  representation  was  removed  by  translating  the 
TLS  into  TAME  since  the  state  machine  semantics  under¬ 
lying  TAME  is  expressed  as  a  PVS  theory.  One  component 
of  the  TLS  in  particular,  the  access  control  matrix,  facilitated 
communication  between  the  formal  methods  team  and 
other  stakeholders.  Although  the  matrix  was  largely 
redundant  of  other  parts  of  the  TLS,  stakeholders  could 
easily  understand  the  matrix  and  thus  validate  constraints 
on  the  access  privileges  of  processes  invoked  by  each  event. 
The  matrix  was  also  useful  in  identifying  the  events  and 
MAIs  to  be  included  in  the  TLS. 

6.3  Mechanized  Verification 

TAME's  specification  and  proof  support  significantly 
simplified  the  verification  effort  and  required  a  total  of 
about  3.5  weeks.  Approximately  1.5  weeks  was  required  to 
produce  the  final  TAME  model  of  the  TLS  and  to  document 
the  correspondence  between  the  TAME  model  and  the  TLS. 
Some  of  this  time  was  required  to  choose  appropriate  data 
structures  for  representing  the  state  variables  and  the 
parameters  of  actions  in  TAME.  The  higher  order  nature 
of  PVS  made  it  feasible  to  handle  the  unspecified  number  of 
memory  areas  in  the  TLS  by  representing  the  overall 
memory  content  in  TAME  as  a  function  from  a  set  of 
memory  areas  to  storable  values  and,  in  general,  to  produce 
a  very  compact  TAME  specification  (368  lines  long).  Once 
the  data  representations  were  chosen,  translating  the  TLS 
and  the  five  subproperties  into  TAME  required  only  three 
days.  Adjusting  the  TAME  specification  to  reflect  later 
changes  in  the  TLS  required  only  a  few  hours.  To  illustrate 
the  TAME  representation,  Appendix  B  provides  TAME 
versions  of  three  of  the  five  subproperties. 

About  two  weeks  was  needed  to  formally  verify  that  the 
TLS  enforces  data  separation.  Most  of  this  time  was  spent 
formulating  an  efficient  proof  approach  and  then  developing 
a  new  TAME  strategy  to  implement  the  approach.  The  new 
PVS  strategy,  designed  to  simplify  the  proof  guidance  in  the 
presence  of  the  data  structures  used  in  the  TAME  specifica¬ 
tion,  was  used  in  the  proofs  of  all  subproperties  and  has 
subsequently  proven  useful  in  other  TAME  applications. 
Once  the  strategy  was  developed,  the  time  required  to 
develop  the  proof  scripts  interactively  in  TAME  was  one  day. 
Adding  and  proving  a  new  subproperty  suggested  by  an 
evaluator  required  under  one  hour.  The  proof  script  of  each 
subproperty  executes  in  two  minutes  or  less. 
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6.4  Showing  Code  Conformance 

For  one  month,  we  experimented  with  several  different 
approaches  for  demonstrating  conformance  between  the 
TLS  and  the  annotated  C  code  before  the  approach 
presented  in  Section  3.5  was  selected.  Once  an  approach 
was  selected,  a  total  of  about  five  weeks  was  required  to 
establish  conformance.  The  formal  foundation  for  the 
correspondence  argument  required  one  week.  Three  weeks 
were  needed  to  construct  the  correspondence  of  Event  Code 
to  TLS  events,  that  is,  developing  the  code-level  assertions 
necessary  for  the  TLS  preconditions  and  postconditions  to 
hold  and  locating  the  corresponding  event  code  and  asser¬ 
tions  in  the  annotated  C  code.  One  day  was  spent  using  the 
Xcode  tool  to  locate  all  calls  to  functions  that  can  reset  the 
MMU  and  manually  verifying  that  the  permissions  for  the 
Other  Code  did  not  include  access  to  MAIs.  One  week  was 
needed  to  add  the  required  assertions  to  the  annotated  code. 
Our  method  for  demonstrating  code  conformance  in  the  ED 
kernel  relies  on  the  notions  of  MAIs  and  Event  Code.  The 
extent  to  which  our  method  can  be  extended  to  other 
applications  depends  on  whether  an  analogous  method  of 
identifying  the  Event  Code  (and  the  Trusted  Code)  can  be 
found.  In  addition,  as  noted  in  Section  5.1,  in  our  method,  the 
properties  to  be  proven  must  be  preserved  under  refinement. 
Both  the  EM  class  of  applications  and  the  applications  that 
enforce  access  control  policies  are  likely  to  meet  both 
conditions. 

7  Open  Problems 

7.1  Code  Annotations 

For  many  years,  some  researchers  have  recommended 
annotating  code  with  preconditions,  postconditions,  and 
invariants  (for  example,  see  [35],  [36]).  Such  code  annota¬ 
tions  are  already  used  in  practice.  For  example,  developers 
at  Praxis  annotate  SPARK  programs  with  assertions  and  use 
tools  to  automatically  check  the  assertions  [37].  Further¬ 
more,  in  the  largest  Microsoft  product  groups,  annotations 
are  a  mandated  part  of  the  software  development  process 
[38].  However,  manual  annotation  of  source  code  remains 
rare  in  the  wider  software  development  industry  because  it 
is  highly  labor  intensive  [39].  Although  tools  for  checking 
code  annotations  would  be  valuable,  tools  that  can 
construct  preconditions  and  postconditions  automatically 
are  even  more  valuable.  Some  promising  initial  research  on 
the  automatic  extraction  of  a  specification  from  code  has 
been  published  (for  example,  see  [40]).  However,  to  date, 
current  research  has  mostly  focused  on  extracting  specifica¬ 
tions  to  detect  code  vulnerabilities.  Extracting  assertions 
from  code  for  checking  security  properties  such  as  access 
privileges  and  other  assertions,  like  those  shown  in  Fig.  1, 
has  not  been  investigated. 

7.2  Automatic  Generation  of  Test  Cases  from 
Assertions 

Recently,  many  new  techniques  for  specification-based 
testing  have  been  proposed.  Such  techniques  (see,  for 
example,  [41])  construct  a  set  of  test  cases  for  checking  a 
software  implementation  against  a  formal  requirements 
specification.  One  promising  new  direction  would  be  to 
construct  test  cases  from  preconditions  and  postconditions 
that  annotate  the  source  code  and  then  use  the  test  cases  to 
check  that  a  given  program  (such  as  a  program  that 


includes  the  annotated  C  code  in  Fig.  1)  satisfies  the 
asserted  preconditions  and  postconditions.  Validating  the  C 
code  in  this  manner  would  provide  high  assurance  of  both 
the  security  and  functional  correctness  of  the  C  code. 
Reference  [42]  describes  an  approach  that  uses  automatic 
test  case  generation  from  preconditions  and  postconditions 
to  find  bugs  in  Java  code. 

7.3  A  Code  Conformance  Proof  Assistant 

The  semantic  distance  between  the  abstract  TLS  required 
for  a  Common  Criteria  evaluation  and  a  low-level  C 
program  is  huge.  Although  the  TLS  describes  the  security¬ 
relevant  program  behavior  in  terms  of  sets,  functions,  and 
relations,  the  description  of  the  behavior  of  a  C  program  is 
in  terms  of  low-level  constructs  such  as  arrays,  integers,  and 
bits  stored  in  registers  and  memory  areas.  Hence,  an 
automatic  demonstration  of  conformance  of  low-level  C 
code  to  a  TLS  is  unrealistic.  A  more  realistic  goal  is  a  proof 
assistant  with  two  inputs — a  C  program  annotated  with 
assertions  and  a  TLS  of  the  security-relevant  functions  of 
that  program — for  helping  the  user  establish  that  the  C 
program  satisfies  the  TLS. 

7.4  Automatic  Code  Generation 

One  promising  way  of  obtaining  high  assurance  that  an 
implementation  satisfies  a  set  of  critical  security  properties 
is  to  generate  code  automatically  from  a  specification  that 
has  been  proven  to  satisfy  the  properties.  Automatic  code 
generation  is  already  feasible  for  some  low-level  specifica¬ 
tion  languages  such  as  Esterel  [43].  Although  constructing 
efficient  source  code  from  more  abstract  specifications  is 
possible  for  simple  program  constructs  using  simple  data 
types  (for  example,  see  [44]),  new  research  is  needed  to 
produce  efficient  code  from  specifications  containing  richer 
constructs  and  data  types.  Such  technology  should  drasti¬ 
cally  reduce  the  effort  required  to  produce  efficient  code 
and  to  increase  assurance  that  the  code  satisfies  critical 
security  properties. 

8  Related  Work 

In  the  1980s,  the  SCOMP  [45],  SeaView  [46],  LOCK  [47],  and 
Multinet  Gateway  [48]  projects  all  applied  formal  methods 
to  the  specification  and  verification  of  systems.  All  devel¬ 
oped  TLSs  and  formal  statements  of  the  system  security 
policies.  For  SCOMP,  Multinet  Gateway,  and  LOCK,  the 
TLS  was  formally  shown  to  satisfy  the  security  policy.  For 
SeaView,  only  two  of  the  31  operations  in  the  TLS  were 
verified  against  the  security  policy  model  [6].  Conformance 
between  the  TLS  and  the  SCOMP  code  was  shown  by 
constructing  several  mappings:  the  English  language  to  the 
TLS,  the  TLS  to  pseudocode,  and  the  TLS  to  actual  code  [5]. 
The  mapping  was  top  down  from  the  TLS  to  the  code.  As  a 
result,  some  code  was  unmapped.  This  approach  is  similar  to 
our  mapping  of  Event  Code  to  the  TLS,  although  the  mapping 
is  in  the  other  direction.  The  LOCK  project  constructed 
mappings  partially  relating  the  TLS  to  the  source  code. 
Specification-based  testing  provided  additional  evidence  of 
correspondence.  In  Multinet  Gateway,  verification  condi¬ 
tions  were  generated  to  show  conformance  between  the 
specification  and  the  code.  If  and  how  these  conditions  were 
discharged  is  unclear.  Each  project  used  tools  to  aid  in 
specification  and  verification:  SCOMP  used  HDM  [49], 
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Seaview  used  EHDM  [50],  and  Multinet  Gateway  and  LOCK 
used  Gypsy  [51].  More  recently,  in  2006,  we  formulated  a 
second  possible  approach  to  software  verification  based  on 
TAME,  which  uses  verified  formal  pseudocode  as  "glue" 
relating  a  TLS  to  actual  code  [52]. 

In  [34],  [53],  Greve,  Wilding,  and  Vanfleet  (GWV)  present 
an  ACL2  model  for  a  generic  separation  kernel.  In  the 
model,  a  function  describes  the  possible  information  flows 
between  memory  areas.  This  notion  of  flow  is  not  as  fine¬ 
grained  as  our  model,  where  access  (with  its  possible 
information  flows)  is  granted  to  each  process  only  when  it 
executes  in  a  partition,  thus  providing  least  privilege  in 
addition  to  separation.  In  the  GWV  approach,  separation 
includes  No-Exfiltration  and  No-Infiltration  but  not  Tem¬ 
poral  Separation  since  the  model  does  not  allow  reconfigur- 
able  partitions.  How  the  GWV  model  was  used  to  verify  the 
AAMP7  microprocessor  is  described  in  [54],  [55].  A 
traditional  verification  process  was  followed:  Build  a  formal 
security  policy,  both  an  abstract  and  a  detailed  model,  and 
an  implementation,  then  prove  that  the  abstract  model 
satisfies  the  security  policy  and  show  correspondence 
between  the  abstract  and  detailed  models  and  between 
the  detailed  model  and  the  implementation.  Whether 
correctness  was  proven  at  either  the  detailed  design  level 
or  the  code  level  is  unclear. 

9  Conclusions 

This  paper  has  introduced  a  novel  and  affordable  approach 
for  verifying  security  down  to  the  source  code  level.  The 
approach  begins  with  a  well-defined  security  property, 
builds  the  minimal  state  machine  model  needed  to  prove 
that  the  model  satisfies  the  property,  and  proves,  using  a 
mechanical  verifier,  that  the  security  model  satisfies  the 
property.  Once  complete,  the  code  is  annotated  with 
preconditions  and  postconditions  and  is  then  partitioned 
into  Event,  Trusted,  and  Other  Code.  The  final  step  is  to 

1)  demonstrate  conformance  of  the  Event  Code  and  the 
code  preconditions  and  postconditions  with  the  internal 
events  and  preconditions  and  postconditions  of  the  TLS  and 

2)  show  that  the  Trusted  Code  and  the  Other  Code  are 
benign.  Tools  such  as  model  checkers  and  theorem  provers 
are  already  available  for  verifying  that  a  formal  specifica¬ 
tion  satisfies  a  security  property  of  interest.  A  research 
challenge  is  to  develop  tools  for  the  following: 

1 .  validating  and  constructing  preconditions  and  post¬ 
conditions  from  the  source  code,  including  the 
C  code, 

2.  automatically  generating  test  cases  that  check  C  code 
annotations, 

3.  showing  conformance  of  annotated  code  with  a  TLS, 
and 

4.  automatically  constructing  efficient  provably  correct 
code  from  specifications. 

Research  that  addresses  these  four  problems  should 
significantly  increase  the  affordability  of  constructing 
verified  security-critical  software. 
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Fig.  3.  Relationships  in  successive  refinements. 

Appendix  A 

Iterating  Our  Refinement  Method 

Fig.  3  illustrates  the  mappings,  predicates,  and  relationships 
between  assertions  connected  with  the  proof  of  successive 
refinements  from  an  automaton  at  level  c  through  an 
automaton  at  level  b  to  an  automaton  at  level  a.  We  wish  to 
prove  that  if  the  analogs  of  conditions  1,  2,  and  3  from 
Section  4.1  hold  for  the  c-to-b  and  b-to-a  relations,  then 
conditions  1,  2,  and  3  hold  for  the  composed  c-to-a  relation 
in  which  q  =  qi  o  q2  and  o  $i.  In  analogy  with  the 

notation  in  Section  4,  we  use  sb  to  denote  a2 (sc),  sa  to  denote 
oci(sb),  and  £a,  <Sb,  and  Sc  to  denote  the  sets  of  states  at 
levels  a,  b,  and  c.  We  first  need  a  lemma. 

Lemma  A.l.  Let  a  :  5C  — >  S'a  and  let  $  be  the  map  from 
predicates  on  Sa  to  predicates  on  Sc  induced  by  a,  that  is,  such 
that,  for  any  predicate  Pa  and  any  element  sc  G  Sc, 
<E(Pa)(sc)  =  Pa(a(sc)).  If  Pa  and  Qa  are  predicates  on  Sa 
such  that  Pa  =>  Qa,  then  4>(Pa)  =>  4>(Qa). 

Proof.  Suppose  that  Pa  and  Qa  are  two  predicates  on  S&/ 
for  which  Pa  =>  Qa.  This  means  that,  Vsa  G  5a, 
Pa(sa)  =>  Qa(sa).  Let  sc  be  any  element  of  Sc-  Then, 

4>(Pa)(sc)  =  Pa(a($c))  (by  the  definition  of  $) 

=>  Qa(a(«c))  (since  Pa  =>  Qa) 

=  4>(Qa)(sc)  (by  the  definition  of  4>). 

□ 


Next,  we  define  the  notion  of  an  annotated  transition. 

Definition  A.l.  Let  S  be  a  set  of  states  and  let  E  c  S  x  S  be  a 
set  of  transitions  on  S.  An  annotated  transition  is  a  transition 
e  G  E  accompanied  by  a  one-state  predicate  Pree  on  S  and  a 
two-state  predicate  Poste  on  S. 

Now,  we  can  state  the  theorem  formally: 

Theorem  A.2.  Let  A,  B,  and  C  be  automata  with  state  spaces  Sb, 
Sb,  and  Sc  and  sets  of  annotated  transitions  E&,  Eb,  and  Ec, 
respectively.  Let  a2  :  Sc  — >  Sb  and  Ec  — >  Eh  and  a\  :  Sb~> 
S&  and  Eb  — >  E&  be  refinement  mappings,  that  is,  mappings 
that,  together  with  their  induced  mappings  4>2  and  4>i  on 
predicates  and  the  transition  annotations,  satisfy  the 
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appropriate  analogs  of  conditions  1,  2,  and  3  from 
Section  4.1.  For  convenience,  we  refer  to  these  conditions 
as  conditions  lb;C,  \ C/  and  3b, c  and  conditions  la>b,  2ajb,  and 
3a,b-  Then  if  a  =  a i  o  a2  and  $  =  $2  °  $i,  the  mappings  a 
and  $  satisfy  conditions  1,  2,  and  3,  and  hence,  a  :  Sc^>  Sa, 
and  Eb  — *  E&  is  a  refinement  mapping. 

Proof.  Suppose  that  the  hypotheses  of  Theorem  A.2  hold. 
Then,  we  need  to  establish  that  conditions  1, 2,  and  3  hold. 
For  condition  1,  we  can  argue  as  follows: 

(i)  Preec  ==>  $2(Preeb)  (by  condition  lb,c) 

(ii)  Pre^  =4>  $i(PreeJ  (by  condition  lab) 

(iii)  $2(Preeb)  =>■  3>2($i(Preea))  (by  (ii)  and  Lemma  A.  1) 
and,  therefore, 

(iv)  PreCc  ==>  3>2($i(Preea))  (by  (i)  and  (iii)) 

(v)  Preec  =>  $(Preea)  (by  the  definition  of  <£>) 

For  condition  2,  first  note  that  the  first  part  of 
condition  2,  which  relates  PreCc  to  Postec,  follows  from 
the  first  part  of  condition  2b, c-  The  remainder  of  the 
argument,  which  relates  Postec  to  Postea,  is  totally 
analogous  to  that  for  condition  1. 

To  prove  condition  3,  we  note  that  if  Preec(sc)  holds, 
then  by  condition  3b, C/  the  lower  square  in  Fig.  3 
commutes.  Furthermore,  we  have 

Preec(sc) 

=>  $2(Preeb)(sc)  (by  condition  lb, c) 

=  Preet(sb)  (by  definition  of  $2,  since  sc  =  02(sb)) 

and  hence  Preeb(sb)  holds.  By  condition  3a,b,  this  implies 
that  the  upper  square  commutes.  Therefore,  the  diagram 
as  a  whole  commutes  and  we  have 

ea  °  ai  o  02  =  c^i  0  0  ec. 

By  the  definition  of  a,  this  means  that 

6^  O  CX  —  (X  O  6(j } 

and  we  are  done.  □ 

Appendix  B 

TAME  Representation  of  Separation 

To  provide  some  details  of  the  TAME  representation  of  ED, 
we  show  how  three  of  the  five  subproperties  of  the 
separation  property  verified  for  ED,  Temporal  Separation, 
No-Exfiltration,  and  No-Infiltration,  are  represented  in 
TAME.  For  each  subproperty,  we  first  repeat  its  natural 
language  representation  from  Section  3.2  and  then  show 
and  explain  its  TAME  representation. 

B.1  Temporal  Separation 

Natural  language  version 

(Temporal  Separation)  For  all  states  s  in  5,  for  all  i,  1  <  i  <  n, 
if  the  partition  id  cs  is  0,  then  the  k  data  areas  of  partition  i 
are  clear,  that  is,  D\s  —  0, . . . ,  D\s  —  0. 


TAME  version 

Inv_ClearPart (s : states) : bool  = 

(FORALL  (i: Partlndex) :  (NONE?  ( Partld (s ) )  => 
(F0RALL  (n: DataArealndex) : 

Clear? (MemContent (DataArea (i, n) , s) ) ) ) ) ; 

lemma_ClearPart :  LEMMA  (FORALL  (sistates): 
reachable(s)  =>  Inv_ClearPart (s) ) ; 

The  TAME  representation  of  the  Temporal  Separation 
property  is  the  state-invariant  lemma  lemina_ClearPart, 
which  states  that  the  invariant  Inv_ClearPart  holds  for 
every  reachable  state  s.  In  the  invariant  Inv_ClearPart, 
Partlndex  and  DataArealndex  are  the  types  of  partition 
indices  and  data  area  indices,  defined  simply  to  be 
nonempty,  uninterpreted  types.  Thus,  there  can  be  an 
arbitrary  nonzero  number  of  partitions,  each  with  the  same 
but  arbitrary  nonzero  number  of  data  areas.  Partld(s) 
represents  cs,  the  current  partition  id  in  the  current  state. 
N0NE?(PartId(s))  is  true  when  c,s.  is  0,  that  is,  exactly  when 
no  partition  processing  is  taking  place.  MemContent  is  a 
function  that  maps  a  memory  area  and  a  state  to  the 
memory  content  of  that  memory  area  in  that  state.  Finally, 
the  predicate  Clear?  is  true  of  the  memory  content  of  a  data 
area  when  that  data  area  is  clear. 

B.2  No-Exfiltration 

Natural  language  version 

(No-Exfiltration)  Suppose  that  states  s  and  s'  are  in  state  set  S, 
event  e  is  in  H,  memory  area  a  is  in  M,  and  j  is  a  partition, 

1  <  j  <n.  Suppose  further  that  s'  —  T(e ,  s).  If  e  is  an  event  in 
Pj  U  Ef  U  Efut  and  as  +  <v,  then  a  is  in  Aj. 

TAME  version 

No_Exfiltration:  LEMMA 
(FORALL  (E: actions,  s: states,  m:MemAreas, 
j : Partlndex) : 

(enabled (E, s )  &  Isin (m, PartMemAreas ( j ) )  & 

(NONE? (Partld (s) )  OR 

(Part?  (Partld(s) )  &  NOT (Id (Partld (s) ) =j ))) ) 

=>  ( (InBuff?  (E)  &  InBuf f_Index ( E ) = j )  OR 

(OutBuff? (E)  &  OutBuf f_Index ( E ) =j )  OR 
MemContent (m, s ) =MemContent (m, trans (E, s) ) ) ) ; 

The  TAME  version  No_Exf  iltration  of  the  No-Exfiltration 
property  corresponds  to  the  contrapositive  of  the  natural 
language  version.  In  the  TAME  representation,  the  event  e  is 
represented  by  an  action  E.  The  state  s  is  represented  by  s 
and  the  state  s'  is  represented  by  trans (E,  s),  that  is,  the 
result  of  a  transition  due  to  action  E  in  state  s.  For  the  current 
partition  id  Partld(s)  in  state  s,  either  NONE?  holds,  that  is, 
no  partition  processing  is  occurring,  or  Part?  holds,  in 
which  case,  partition  processing  is  occurring  in  partition 
id(PartId(s)).  The  assertion  enabled(E,  s)  means  that  the 
precondition  of  action  E  holds  in  state  s.  When  E  is  an 
internal  action,  this  precondition  ensures  that  E  is  an 
internal  action  for  Partition  Partld(s).  The  condition 
InBuff?(E)&InBuff_Index(E)  =  j  is  true  when  E  fills  the 
input  buffer  of  Partition  j.  The  analogous  condition  with 
Out  in  place  of  In  is  true  when  E  empties  the  output 
buffer  of  Partition  j.  These  parts  of  the  conclusion  of 
property  No_Exf iltration  cover  the  cases  when  action  E 
is  an  external  event  for  Partition  j .  Thus,  property 
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No_Exf iltration  says  that,  if  m  is  a  memory  area  in 
Partition  j  and  E  either  is  an  external  action  or  is  an 
internal  action  in  some  partition  other  than  Partition  j ,  then 
either  E  is  an  external  action  for  Partition  j  or  E  does  not 
change  the  content  of  m. 

B.3  No-Infiltration 

Natural  language  version 

(No-Infiltration)  Suppose  that  states  s\,  S2,  s'v  and  s'2  are  in  S, 
event  e  is  in  H,  and  i  is  a  partition,  1  <i  <n.  Suppose 
further  that  =  T(e,  si)  and  s2  —  T(e,  S2).  If,  for  all  a  in  Aif 
aSl  —  aS2,  then,  for  all  a  in  Ai,  as'  =  a^. 

TAME  version 

No_Inf iltration:  LEMMA 

(FORALL  (E: actions,  si, s2 : states,  m:MemAreas, 
i : Partlndex) : 

enabled (E, si)  &  enabled (E, s2)  & 

Part? (Partld(sl) )  &  Id(PartId(sl) )=i  & 

Part? (Part Id (s2) )  &  Id (Partld ( s2 ) ) =i  & 

Isin(m,  PartMemAreas (i) )  & 

(FORALL  (ml :MemAreas) : Isin (ml, PartMemAreas (i) ) 
=>  MemContent (ml, si) =MemContent (ml, s2) ) 

=>  MemContent (m, trans (E,  si ) ) 

=  MemContent (m, trans (E, s2 ))) ; 

The  preceding  explanation  of  the  notation  in 
lemma_ClearPart  and  No_Exf iltration  should  make  it 
clear  that  the  TAME  version  No_Inf iltration  of  the  No- 
Infiltration  Property  is  equivalent  to  the  natural  language 
version. 
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